Java Refection : NoSuchMethodException on high load - java

I am getting below exception ONLY when high load is running like 25 calls (same scenario) per second and it is not coming for every call, it is coming for few times only.However, when I run few calls at a time i am not getting this exception. I checked that method public execute method exists in com.abc.block.Rules class and this is the reason exception is not coming when i run few calls.
02 Oct 2019 02:00:01,021 [Worker[23]] ERROR [SNode] 80]
NoSuchMethodException during reflective call on class
com.abc.block.Rules java.lang.NoSuchMethodException:
com.abc.block.Rules.execute(com.abc.common.cdata) at
java.lang.Class.getMethod(Class.java:1786)
While running load reflection is not working correctly. Any inputs please ?
Code :
Object port = service.getClass()
.getMethod(xmlSNode.getPortMethodName()).invoke(service);
outResult = port
.getClass()
.getMethod(xmlSNode.getOperation().getName(),
inputs.getInputTypes())
.invoke(port, data);
Rule call :
public Object[] execute(cdata c) throws Exception{
...
}
Any input please

Related

Hyperledger Fabric: How to return error in Java chaincode so it goes back to fabrik-java-sdk client

let's say my Java chaincode (running on Fabric 1.4.4) wants to throw an exception to show that the new asset to be created already exists. I am throwing a RunTimeException with the problem or error (In this case, "Contract LL00001 already registered") which is logged in the Peer node executing the transaction:
2019-11-29 20:15:37.807 UTC [peer.chaincode.nid1-blockchain-hapeer1-mrrc-0.1.4] func2 -> INFO 16a8ec Contract LL00001 already registered
2019-11-29 20:15:37.807 UTC [peer.chaincode.nid1-blockchain-hapeer1-mrrc-0.1.4] func2 -> INFO 16a8ed java.lang.RuntimeException: Contract LL00001 already registered
But then, after the stack trace I see that the peer node is returning it as 500 error without includeing my error description or any reference to the error Exception in java (this makes sense as that error is language agnostic):
2019-11-29 20:15:37.807 UTC [peer.chaincode.nid1-blockchain-hapeer1-mrrc-0.1.4] func2 -> INFO 16a8ff 20:15:37:804 SEVERE org.hyperledger.fabric.shim.impl.ChaincodeInnvocationTask call [1f56a053] Invoke failed with error code 500. Sending ERROR
Which is logged in my client java application (which uses fabrik-java-sdk):
org.hyperledger.fabric.sdk.exception.InvalidArgumentException: Proposal response is invalid.
at org.hyperledger.fabric.sdk.ProposalResponse.getChaincodeActionResponsePayload(ProposalResponse.java:272)
at ...
So I just know that there was a problem from the chaincode, but I can't know what the problem is. How can I get the error type and description so I can show the problem to the user? Now I need to go to the peer node an check logs there to see what problem is.
Note: I am extending the new org.hyperledger.fabric.contract.ContractInterface in my chaincode class.
Update: peer node logs the error exception (org.hyperledger.fabric.shim.ChaincodeException) and seems to return correctly the error message ("The document was not found") in the 500 response as shown in log, but this message does not get to Java SDK
2019-12-23 22:11:09.178 UTC [peer.chaincode.nid1-blockchain-hapeer1-mrrc-0.9.7] func2 -> INFO 5aa7 22:11:09:176 SEVERE org.hyperledger.fabric.shim.impl.ChaincodeInnvocationTask call [12cc4ad0] Invoke failed with error code 500. Sending ERROR
2019-12-23 22:11:09.179 UTC [peer.chaincode.nid1-blockchain-hapeer1-mrrc-0.9.7] func2 -> INFO 5aa8 22:11:09:177 FINE org.hyperledger.fabric.shim.impl.ChaincodeSupportClient$2 accept > sendToPeer 12cc4ad09a1feb7fc1246ac04bf69509204ca74368be2c7e4bbf0a503e90417f
2019-12-23 22:11:09.181 UTC [endorser] callChaincode -> INFO 5aa9 [mrrc][12cc4ad0] Exit chaincode: name:"mrrc" (36ms)
2019-12-23 22:11:09.181 UTC [endorser] SimulateProposal -> ERRO 5aaa [mrrc][12cc4ad0] failed to invoke chaincode name:"mrrc" , error: transaction returned with failure: The document was not found
Edit: It seems to be a error in Java SDK. I have created a JIRA issue in Fabric's JIRA:
https://jira.hyperledger.org/browse/FABJ-508
To throw this error back to your fabric java sdk client, one way would be to make your chaincode class extend the ChaincodeBase class (which can be imported in your java program by importing org.hyperledger.fabric.shim ) and then you can use its newErrorResponse method in each of your chaincode methods to throw your custom errors wherein you can provide the error string as it's first (or only) parameter. You can possibly have a look at this example from the fabric samples repo:
https://github.com/hyperledger/fabric-samples/blob/master/chaincode/abstore/java/src/main/java/org/hyperledger/fabric-samples/ABstore.java#L28
To have a look at the overloaded implementations of the newErrorResponse method, so that you can see what other possible params you can pass to it, please follow:
https://jar-download.com/artifacts/org.hyperledger.fabric-chaincode-java/fabric-chaincode-shim/1.4.0/source-code/org/hyperledger/fabric/shim/ChaincodeBase.java
UPDATE : If you are using the newer chaincodeInterface (as suggested by icordoba) for your chaincode implementations instead, then you should throw an instance of ChaincodeException class which can be imported by importing org.hyperledger.fabric.shim.ChaincodeException, to achieve the same, you can have a look at a sample chaincode here

What this java.lang.Throwable error in mongodb socket means?

I trying to understand what is that error. It starts to happen when I put the mongoDB in another instance.
The error has a big message, but it doesn't say anything, and there's no action known which triggers it.
AT Tue Jan 12 19:34:31 UTC 2016
BY :[java.lang.Thread.getStackTrace(Thread.java:1552), com.sun.enterprise.loader.ASURLClassLoader.done(ASURLClassLoader.java:216), com.sun.enterprise.loader.ASURLClassLoader.preDestroy(ASURLClassLoader.java:184), org.glassfish.javaee.full.deployment.EarClassLoader.preDestroy(EarClassLoader.java:114), org.jvnet.hk2.internal.ServiceLocatorImpl.preDestroy(ServiceLocatorImpl.java:956), org.jvnet.hk2.internal.ServiceLocatorImpl.preDestroy(ServiceLocatorImpl.java:940), org.glassfish.internal.data.ApplicationInfo.clean(ApplicationInfo.java:451), com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:1071), com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1099), org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:412), com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539), com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535), java.security.AccessController.doPrivileged(Native Method), javax.security.auth.Subject.doAs(Subject.java:360), com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534), com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565), com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557), java.security.AccessController.doPrivileged(Native Method), javax.security.auth.Subject.doAs(Subject.java:360), com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556), com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464), com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109), com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846), com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722), org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404), org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234), sun.reflect.GeneratedMethodAccessor419.invoke(Unknown Source), sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43), java.lang.reflect.Method.invoke(Method.java:497), org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81), org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:151), org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171), org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152), org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104), org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:387), org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:331), org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:103), org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:271), org.glassfish.jersey.internal.Errors$1.call(Errors.java:271), org.glassfish.jersey.internal.Errors$1.call(Errors.java:267), org.glassfish.jersey.internal.Errors.process(Errors.java:315), org.glassfish.jersey.internal.Errors.process(Errors.java:297), org.glassfish.jersey.internal.Errors.process(Errors.java:267), org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:297), org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:254), org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028), org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:365), org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173), org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179), com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459), com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167), org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201), org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175), org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235), org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119), org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284), org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201), org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133), org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112), org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77), org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231), org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119), org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284), org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201), org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133), org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112), org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77), org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231), org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119), org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284), org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201), org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133), org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112), org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77), org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561), org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112), org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117), org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56), org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137), org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565), org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545), java.lang.Thread.run(Thread.java:745)] Parent -> org.glassfish.internal.api.DelegatingClassLoader#7cbe8ac6
was requested to find class org.bson.codecs.EncoderContext$1 after done was invoked from the following stack trace
java.lang.Throwable
at com.sun.enterprise.loader.ASURLClassLoader.findClassData(ASURLClassLoader.java:825)
at com.sun.enterprise.loader.ASURLClassLoader.findClass(ASURLClassLoader.java:742)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.bson.codecs.EncoderContext.(EncoderContext.java:27)
at org.bson.codecs.EncoderContext$Builder.build(EncoderContext.java:67)
at com.mongodb.connection.RequestMessage.addDocument(RequestMessage.java:168)
at com.mongodb.connection.CommandMessage.encodeMessageBody(CommandMessage.java:69)
at com.mongodb.connection.RequestMessage.encode(RequestMessage.java:132)
at com.mongodb.connection.CommandHelper.sendMessage(CommandHelper.java:88)
at com.mongodb.connection.CommandHelper.executeCommand(CommandHelper.java:32)
at com.mongodb.connection.DefaultServerMonitor$ServerMonitorRunnable.lookupServerDescription(DefaultServerMonitor.java:186)
at com.mongodb.connection.DefaultServerMonitor$ServerMonitorRunnable.run(DefaultServerMonitor.java:134)
at java.lang.Thread.run(Thread.java:745)
]]
Error message image:
Edit:
People from Payara Server github issue helped me to find the problem. I have used the ServletContextListener to kill the mongo connections before the deploy. Now, I'll wait some time to see if the problem is solved. Code bellow:
#Log
#WebListener
public class AppServletContextListener implements ServletContextListener {
#Inject
MongoClientProvider mongo;
#Override
public void contextDestroyed(ServletContextEvent arg) {
log.info("ServletContextListener destroyed");
DbUtils.closeMongoConnections(mongo);
}
#Override
public void contextInitialized(ServletContextEvent arg) {
log.info("ServletContextListener started");
}
}
.
public class DbUtils {
public static void closeMongoConnections(MongoClientProvider mongo) {
mongo.getDeletedGroups().getManager().close();
mongo.getMessages().getManager().close();
mongo.getGameficationInfos().getManager().close();
mongo.getDgsa().getManager().close();
mongo.getRisa().getManager().close();
mongo.getExpiredEmailLinks().getManager().close();
}
}
You've chopped off the useful bit from the error, but it's present in your screenshot. There will be a bit before the AT Tue Jan 12 19:34:31 UTC 2016 part as well which will tell you that the error is coming from the ASURLClassLoader telling you a bit about the state of the class loader.
The key part is the last line in the image:
...
was requested to find class org.bson.codecs.EncoderContext$1 after done was invoked from the following stack trace
The done() method that it's talking about is a cleanup method that is called when the classloader is ready to be garbage collected. So, at this point, the EncoderContext class is trying to load a class, but the ASURLClassLoader it reaches is in this kind of limbo state between being marked for cleanup, but not yet cleaned up.
I have seen a similar problem before, and I'm currently investigating it for Payara Server, which is derived from GlassFish. I would really appreciate it if you could raise an issue in the Payara Github repository:
https://github.com/payara/Payara/issues
T̶h̶i̶s̶ ̶m̶i̶g̶h̶t̶ ̶b̶e̶ ̶a̶ ̶b̶u̶g̶ ̶i̶n̶ ̶G̶l̶a̶s̶s̶F̶i̶s̶h̶ ̶a̶n̶d̶ ̶P̶a̶y̶a̶r̶a̶ ̶S̶e̶r̶v̶e̶r̶ ̶s̶o̶ ̶p̶r̶o̶b̶a̶b̶l̶y̶ ̶n̶o̶t̶ ̶a̶p̶p̶r̶o̶p̶r̶i̶a̶t̶e̶ ̶t̶o̶ ̶d̶i̶s̶c̶u̶s̶s̶ ̶a̶t̶ ̶l̶e̶n̶g̶t̶h̶ ̶o̶n̶ ̶a̶ ̶Q̶&̶A̶ ̶s̶i̶t̶e̶!̶
Edit: Actually, looking closer at the ASURLClassLoader stack (the big screenshot) it looks like done() was called because of an undeployment. So it is probably that MongoDB was called from within an application that was undeployed and MongoDB was not disposed of at the same time.
This may have been what you wanted, but in that case, the MongoDB resource should not have been created from within the application. Otherwise, it needs to be destroyed properly before the application is undeployed.

How does JVM handle runtime exception in RMI remote method?

I have been trying to find out how JVM handles runtime exception in RMI remote methods. I have a remote method that contains the following two methods:
doSomething(
print "doSomething thread id " + Thread.currentThread.getId()
)
fail(){
print "fail thread id " + Thread.currentThread.getId()
throw new RunTimeException
}
The behavior I saw was that even if method fail() is invoked, the thread on which the runtime exception was thrown is still not terminated. A sample output is:
fail thread id 16
stacktrace
...
doSomething thread id 16
doSomething thread id 16
The exception is caught. The caller will get a ServerException with your RuntimeException nested in it as the cause. The executing thread doesn't die.

WebService times out, but client receives no exception

I have an application that is attempting to call a service and the other service appears to be timing out. The problem is my application does not receive any timeout exceptions, although I do see an error printed out to the console:
[7/8/13 12:39:32:360 EDT] 00000005 TimeoutManage I WTRN0006W: Transaction 0000013FBF252E43000000010000000CE81CB4935851D5C13DECD3DBB2D463F0DBECAEE60000013FBF252E43000000010000000CE81CB4935851D5C13DECD3DBB2D463F0DBECAEE600000001 has timed out after 120 seconds.
[7/8/13 12:39:32:360 EDT] 00000005 TimeoutManage I WTRN0124I: When the timeout occurred the thread with which the transaction is, or was most recently, associated was Thread[WebContainer : 1,5,main]. The stack trace of this thread when the timeout occurred was:
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:196)
com.ibm.io.async.AbstractAsyncFuture.waitForCompletion(AbstractAsyncFuture.java:334)
com.ibm.io.async.AsyncFuture.getByteCount(AsyncFuture.java:218)
com.ibm.ws.tcp.channel.impl.AioSocketIOChannel.readAIOSync(AioSocketIOChannel.java:215)
com.ibm.ws.tcp.channel.impl.AioTCPReadRequestContextImpl.processSyncReadRequest(AioTCPReadRequestContextImpl.java:182)
com.ibm.ws.tcp.channel.impl.TCPReadRequestContextImpl.read(TCPReadRequestContextImpl.java:111)
com.ibm.ws.http.channel.outbound.impl.HttpOutboundServiceContextImpl.parseResponseMessageSync(HttpOutboundServiceContextImpl.java:1657)
com.ibm.ws.http.channel.outbound.impl.HttpOutboundServiceContextImpl.readSyncResponse(HttpOutboundServiceContextImpl.java:725)
com.ibm.ws.http.channel.outbound.impl.HttpOutboundServiceContextImpl.startResponseReadSync(HttpOutboundServiceContextImpl.java:1775)
com.ibm.ws.http.channel.outbound.impl.HttpOutboundServiceContextImpl.finishRequestMessage(HttpOutboundServiceContextImpl.java:1195)
com.ibm.ws.websvcs.transport.http.out.HttpOutSyncWriter.finishBufferRequest(HttpOutSyncWriter.java:94)
com.ibm.ws.websvcs.transport.http.out.HttpOutWriter.writeBuffer(HttpOutWriter.java:136)
com.ibm.ws.websvcs.transport.http.out.HttpOutByteBufferOutputStream.finish(HttpOutByteBufferOutputStream.java:468)
com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.sendChunkedRequest(SOAPOverHTTPSender.java:890)
com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.sendSOAPRequest(SOAPOverHTTPSender.java:807)
com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.send(SOAPOverHTTPSender.java:611)
com.ibm.ws.websvcs.transport.http.HTTPTransportSender.invoke(HTTPTransportSender.java:364)
org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:531)
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:401)
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:581)
org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.doInvoke(AxisInvocationController.java:130)
org.apache.axis2.jaxws.core.controller.impl.InvocationControllerImpl.invoke(InvocationControllerImpl.java:93)
org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:364)
org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invoke(JAXWSProxyHandler.java:185)
The client is created with these settings:
bindProvider.getRequestContext().put(com.ibm.wsspi.webservices.Constants.RESPONSE_TIMEOUT_PROPERTY , connectionProperties.getProperty(MyService.TIME_OUT));
bindProvider.getRequestContext().put(com.ibm.wsspi.webservices.Constants.CONNECTION_TIMEOUT_PROPERTY , connectionProperties.getProperty(MyService.TIME_OUT));
bindProvider.getRequestContext().put(com.ibm.wsspi.webservices.Constants.READ_TIMEOUT_PROPERTY , connectionProperties.getProperty(MyService.TIME_OUT));
MyService.TIME_OUT has a value of 20000 and I have verified that it is being set correctly.
The code that catches calls the service looks like this:
try
{
response = ((MyServicePortType) myService).doWebServiceOperation(request);
}
catch (Throwable e) //I know, catch Throwable is not very good but right now I'd be happy to catch ANYthing here!
{
log.error("Webservice reported error",e);
}
Even though I've changed my catch block to catch anything, I still don't catch any exceptions. WebSphere detects a transaction timeout, but I don't know why the application doesn't detect a timeout in the web service call. Is there something I'm missing that would cause a proper timeout exception to be thrown so that I can catch it and send the message to the application framework?
Well now I feel silly.
It seems that for WebSphere, these properties (RESPONSE_TIMEOUT_PROPERTY, CONNECTION_TIMEOUT_PROPERTY, etc...) should have their values set in seconds, and I was using milliseconds based on what I'd seen in online examples (that clearly were not intended for WebSphere).
Changing 20000 to 20 has resolved this problem.
The page that suggested I should be assuming seconds instead of milliseconds is this one: http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rwbs_httptransportprop.html

Illegal Access in WebappClassLoader.loadClass

I have a task scheduler implemented in my application. Basically, what i do is schedule some task's to be executed 4 times in a day (like 6 in 6 hours), so the system schedules it to: 00:00, 06:00, 12:00, 18:00.
Ok, i have a class (FlowJobController) which extends the Thread class and in the run() implementation i keep sleeping the thread in 60 to 60 seconds, so it's executed again to check if there's any task to be executed. If true, i run my Job.
Basically the main part it:
rSet = pStmt.executeQuery();
while (rSet.next()) {
long jobId = rSet.getLong("trf_codigo");
String ruleName = rSet.getString("reg_nome");
String ruleParameters = rSet.getString("trf_regra_parametros");
Job job = new Job();
job.setId(jobId);
job.setRuleName(ruleName);
job.setParameters(Functions.stringToList(ruleParameters, "\n"));
FlowJob flowJob = new FlowJob(this, job);
flowJob.start();
}
} catch (Exception ex) {
logger.error(WFRSystem.DEFAULT_USER, system.getCode(), ex);
} finally {
try {
DBConnection.close(pStmt);
DBConnection.close(rSet);
// executede 60 in 60 sec
Thread.sleep(60 * 1000);
} catch (InterruptedException ex) {
logger.error(WFRSystem.DEFAULT_USER, system.getCode(), ex);
}
}
The thing is: When the pStmt.executeQUery() returns records to be executed, it goes into the while and the error appears into the line: Job job = new Job();
The error is:
Exception in thread "FlowJobController" java.lang.NoClassDefFoundError: wfr/com/Job
at wfr.com.FlowJobController.run(FlowJobController.java:112)
Before this error i got this error:
25/09/2012 12:00:09 org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already. Could not load wfr.com.Job.
The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1566)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at wfr.com.FlowJobController.run(FlowJobController.java:112)
The FlowJobController.java:112 is the Job job = new Job();
What am i doing wrong?
The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
If you are saying that your code deliberately threw the IllegalStateException exception, then that is the likely cause of the subsequent problems. If you throw an uncheck exception in static initialization, and that exception propagates, then the class initialization fails, and the class (and all classes that depend on it) are unusable. In this case, it looks like it also caused the webapp to be stopped.
If this is the problem, the solution is "don't do that". Fix whatever is causing the exception to be thrown.
The other possibility is that this is simply a missing class problem:
Well, that sounds not possible (to not be in the war) since i'm running into the eclipse environment and it's in the class folder directory and no errors is shown about not finding those classes...
The class loader won't be looking in the Eclipse classes folder. It will be looking in the webapp directory on your web container (Tomcat, Jetty, whatever).

Categories