beanshell - Deadlock issue - java

Has anyone got any experience of having deadlocks with beanshell? This is something we have been encountering recently in our production system where script execution is blocking other threads, due to it's lock on classloading via tomcat. The following is the stacktrace for the lock owner in thread dump:
"Thread-64" : 150 : BLOCKED : cpu=37812500000 : cpuLoad= 0.0
BlockedCount:93354 BlockedTime:-1 LockName:java.lang.Object#219d66b6 LockOwnerID:151 LockOwnerName:Thread-65
WaitedCount:13 WaitedTime:-1 InNative:false IsSuspended:false at org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.getArchiveEntries(AbstractSingleArchiveResourceSet.java:66)
at org.apache.catalina.webresources.AbstractArchiveResourceSet.getResource(AbstractArchiveResourceSet.java:262)
at org.apache.catalina.webresources.StandardRoot.getResourceInternal(StandardRoot.java:281)
at org.apache.catalina.webresources.Cache.getResource(Cache.java:62)
at org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:216)
at org.apache.catalina.webresources.StandardRoot.getClassLoaderResource(StandardRoot.java:225)
at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2173)
at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:811)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1260)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1119)
at java.lang.Class.forName0(Class.java:-2)
at java.lang.Class.forName(Class.java:348)
at bsh.classpath.ClassManagerImpl.classForName(null:-1)
at bsh.NameSpace.classForName(null:-1)
at bsh.NameSpace.getImportedClassImpl(null:-1)
at bsh.NameSpace.getClassImpl(null:-1)
at bsh.NameSpace.getClass(null:-1)
at bsh.Name.consumeNextObjectField(null:-1)
at bsh.Name.toObject(null:-1)
at bsh.BSHAmbiguousName.toObject(null:-1)
at bsh.BSHAmbiguousName.toObject(null:-1)
at bsh.BSHPrimaryExpression.eval(null:-1)
at bsh.BSHPrimaryExpression.eval(null:-1)
at bsh.BSHVariableDeclarator.eval(null:-1)
at bsh.BSHTypedVariableDeclaration.eval(null:-1)
at bsh.Interpreter.eval(null:-1)
at bsh.Interpreter.eval(null:-1)
at bsh.Interpreter.eval(null:-1)
at my.package.MyClassFile(MyClassFile:2332)
I see that Groovy is a more popular choice for Java scripting, but I haven't seen many posts where it says that bsh can cause deadlocks.
It would be good to get some ideas from SO users.
Regards,

There's a fix for one dead lock in GUI does not start in Java 8 found in Beanshell (almost latest) version 2.0b5.
You can open a new issue in Beanshell project.
It may be connected to ClassManagerImpl:
Bsh has a multi-tiered class loading architecture. No class loader is
created unless/until a class is generated, the classpath is modified,
or a class is reloaded.
Note: we may need some synchronization in here

Related

Hazelcast : Portable Serialization : Incompatible class-definitions with same class-id

I recently upgraded a cluster from 3.7.2 to 3.9.2; shutting down all the boxes.
I'm using Portable Serialization and the current version number in the config file is 6. Yet, after a cold start, the cluster indicates a incompatible class definition.
I've restarted the cluster several times since, yet the same error remains.
How is it possible for the system to remain out of sync for some fields in some classes, yet the version for the class was upgraded?
Log:
Caused by:
com.hazelcast.nio.serialization.HazelcastSerializationException:
Incompatible class-definitions with same class-id:
ClassDefinition{factoryId=1, classId=8, version=6, fieldDefinitions=[
FieldDefinitionImpl{index=0, fieldName='feature', type=UTF, classId=0, factoryId=0, version=6},
FieldDefinitionImpl{index=1, fieldName='value', type=BOOLEAN, classId=0, factoryId=0, version=6}]}
VS
ClassDefinition{factoryId=1, classId=8, version=6, fieldDefinitions=[
FieldDefinitionImpl{index=0, fieldName='feature', type=UTF, classId=0, factoryId=0, version=0},
FieldDefinitionImpl{index=1, fieldName='value', type=BOOLEAN, classId=0, factoryId=0, version=0}]}
Config:
<serialization>
<portable-version>6</portable-version>
<portable-factories>
<portable-factory factory-id="1">
com.MyPortableFactory
</portable-factory>
</portable-factories>
</serialization>
It is a bug in Hazelcast library that got fixed in 3.9.4 and 3.10+.
Issue:
https://github.com/hazelcast/hazelcast/issues/12733
Fix for 3.10:
https://github.com/hazelcast/hazelcast/pull/12734
Fix for 3.9.4:
https://github.com/hazelcast/hazelcast/pull/12735

Why WebSphere's threads hangs up?

I have WAS 7 and Filenet CE 5.1 and have a troubles.
Why WebSphere's threads hangs up. Is it JDBC driver error?
Could you kindly advice me. Thank a lot!
[22.06.16 13:14:58:921 YEKT] 0000001d ThreadMonitor W WSVR0605W: Thread "WebContainer : 15" (00000047) was active for 631301 msec and can be hanged up. Total threads that can be hang up: 69.
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:140)
at com.microsoft.sqlserver.jdbc.TDSChannel.read(IOBuffer.java:1782)
at com.microsoft.sqlserver.jdbc.TDSReader.readPacket(IOBuffer.java:4838)
at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:6150)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatement(SQLServerPreparedStatement.java:402)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtExecCmd.doExecute(SQLServerPreparedStatement.java:350)
at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:5696)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1715)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:180)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:155)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.execute(SQLServerPreparedStatement.java:332)
at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.pmiExecute(WSJdbcPreparedStatement.java:942)
at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.execute(WSJdbcPreparedStatement.java:618)
at com.filenet.engine.dbpersist.DBExecutionElement.execute(DBExecutionElement.java:218)
at com.filenet.engine.dbpersist.DBExecutionContext.getNextResult(DBExecutionContext.java:106)
at com.filenet.engine.dbpersist.DBStatementList.executeStatements(DBStatementList.java:161)
at com.filenet.engine.persist.DBStatementList2.executeStatementsNoResult(DBStatementList2.java:57)
at com.filenet.engine.persist.IndependentPersister.executeChangeWork(IndependentPersister.java:409)
at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:225)
at com.filenet.engine.persist.SubscribablePersister.executeChange(SubscribablePersister.java:172)
at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1266)
at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1146)
at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:618)
the stack indicates that the thread is waiting to recieve data from your database.
Possible causes could include:
the database is down (or unable to communicate over the network)
a deadlock has occurred in the database
you are fetching some really big data set and/or doing so inefficiently such that the statement is taking an excessive amount of time. You never mentioned if your query ever completes or not, but if it does, I suspect this option is the suspect.

Fitnesse : "could not detect death of command line test runner"

Each time we launch a fitnesse test, it ends by saying
Testing was interrupted and results are incomplete
And we have an exception :
Could not detect death of command line test runner.
java.lang.IllegalThreadStateException: process has not exited
at fitnesse.components.CommandRunner.join(CommandRunner.java:79)
at fitnesse.responders.run.slimResponder.SlimTestSystem.bye(SlimTestSystem.java:208)
at fitnesse.responders.run.MultipleTestsRunner.startTestSystemAndExecutePages(MultipleTestsRunner.java:118)
at fitnesse.responders.run.MultipleTestsRunner.internalExecuteTestPages(MultipleTestsRunner.java:88)
at fitnesse.responders.run.MultipleTestsRunner.executeTestPages(MultipleTestsRunner.java:60)
at fitnesse.responders.run.TestResponder.performExecution(TestResponder.java:190)
at fitnesse.responders.run.TestResponder.doExecuteTests(TestResponder.java:72)
at fitnesse.responders.run.TestResponder$TestExecutor.execute(TestResponder.java:106)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:600)
at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395)
at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384)
at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173)
at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)
at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:369)
at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
at org.apache.velocity.runtime.directive.Parse.render(Parse.java:260)
at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207)
at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
at org.apache.velocity.Template.merge(Template.java:356)
at org.apache.velocity.Template.merge(Template.java:260)
at fitnesse.responders.templateUtilities.HtmlPage.render(HtmlPage.java:80)
at fitnesse.responders.run.TestResponder.doSending(TestResponder.java:61)
at fitnesse.responders.ChunkingResponder.startSending(ChunkingResponder.java:66)
at fitnesse.http.ChunkedResponse.sendTo(ChunkedResponse.java:26)
at fitnesse.FitNesseExpediter.sendResponse(FitNesseExpediter.java:96)
at fitnesse.FitNesseExpediter.start(FitNesseExpediter.java:48)
at fitnesse.FitNesseServer.serve(FitNesseServer.java:24)
at fitnesse.FitNesseServer.serve(FitNesseServer.java:17)
at fitnesse.socketservice.SocketService$ServerRunner.run(SocketService.java:109)
at java.lang.Thread.run(Thread.java:736)
Have you encountered the same problem ? How did you solved it ?
fitnesse version : 20121220
It's quite possible that you have a class reference that is hanging out there and that FitNesse cannot close. Or something is calling System.exit().
An example of the first is Selenium WebDriver. You must close() the browserDriver to get a clean end to a test.
The second is something that we unintentionally allowed in the past and has been changed in more recent releases. It's possible that updating to the latest EDGE might solve it.
However, more context is really required, as this is quite likely an issue in your configuration or your fixture.

Changes to a Lotus Domino xpages java application do not propagate to the server

Using Lotus Domino 8.5.2 Fixpack 3
The title sums it up. I have an xpages application that uses java. It seems that any java changes I make, never become visible on the server. It sounds a dead ringer for a cache issue of some kind. The application runs on the server and I see System.out.println statements in the server log, but do not any of the changes I've made to those statements or any new ones I've added.
The code is set to Rebuild Automatically. Still, it never looks like the server sees the changes. Is there some special way I need to build the database (aside from the typical Rebuild All)? Do I need to reset or restart some process on the domino server for it to see the changes?
Any thoughts or ideas would be greatly appreciated.
EDIT 1
I'm returning to this project and, hence, this question. The specific error message I'm getting is:
[6815810:00012-05659] 03/19/2013 09:27:01 HTTP JVM: Managedbean Calendar could not be created Can't instantiate class: 'calendar.CalendarServices'.. java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices. For more detailed inform
ation, please consult error-log-0
[6815810:00012-05659] 03/19/2013 09:27:01 HTTP JVM: xml located in /local/notesdata/domino/workspace/logs
[6815810:00012-05659] 03/19/2013 09:27:01 HTTP JVM: com.ibm.xsp.exception.EvaluationExceptionEx: Error while executing JavaScript action expression
I've tried unchecking automatic build and doing a clean --> rebuild all. I've tried signing the nsf again. I've ensured that I'm on the acl. And, as recommended, I've tried the
restart task http
Command via live console. No matter what I do I'm getting this error. The odd thing is that this project is just a copy --> paste (with rename) of another one that works fine. So, the project works...until I change and recompile...
The log that exception above points to wasn't very helpful. It reads:
<CommonBaseEvent creationTime="2013-03-05T09:01:03.254-06:00" globalInstanceId="EL0a04a8b800013d3af27da200000008" msg="Managedbean Calendar could not be created Can&apos;t instantiate class: &apos;calendar.CalendarServices&apos;.. java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices" severity="50" version="1.0.1">
<extendedDataElements name="CommonBaseEventLogRecord:level" type="noValue">
<children name="CommonBaseEventLogRecord:name" type="string">
<values>SEVERE</values>
</children>
</extendedDataElements>
<extendedDataElements name="CommonBaseEventLogRecord:sourceClassName" type="string">
<values>com.sun.faces.application.ApplicationAssociate</values>
</extendedDataElements>
<extendedDataElements name="CommonBaseEventLogRecord:sourceMethodName" type="string">
<values>createAndMaybeStoreManagedBeans</values>
</extendedDataElements>
<extendedDataElements name="CommonBaseEventLogRecord:Exception" type="string">
<values>javax.faces.FacesException: Can&apos;t instantiate class: &apos;calendar.CalendarServices&apos;.. java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices
at com.sun.faces.config.ManagedBeanFactory.newInstance(ManagedBeanFactory.java:234)
at com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans(ApplicationAssociate.java:291)
at com.sun.faces.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:135)
at com.ibm.xsp.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:71)
at com.ibm.xsp.javascript.ServerSideLocalObject.resolveVariable(ServerSideLocalObject.java:97)
at com.ibm.xsp.javascript.ServerSideLocalObject.resolveAttribute(ServerSideLocalObject.java:73)
at com.ibm.xsp.javascript.AbstractLocalObject._get(AbstractLocalObject.java:119)
at com.ibm.xsp.javascript.AbstractLocalObject.getPropertyReference(AbstractLocalObject.java:101)
at com</values>
<values>.ibm.jscript.engine.ProgramContext.findGlobalScopeIdentifier(ProgramContext.java:143)
at com.ibm.jscript.engine.ProgramContext.findIdentifier(ProgramContext.java:134)
at com.ibm.jscript.ASTTree.ASTIdentifier.interpret(ASTIdentifier.java:105)
at com.ibm.jscript.ASTTree.ASTMember.interpret(ASTMember.java:106)
at com.ibm.jscript.ASTTree.ASTCall.interpret(ASTCall.java:88)
at com.ibm.jscript.ASTTree.ASTArgumentList.interpretArguments(ASTArgumentList.java:63)
at com.ibm.jscript.types.FBSObject.call(FBSObject.java:153)
at com.ibm.jscript.ASTTree.ASTCall.interpret(ASTCall.java:175)
at com.ibm.jscript.ASTTree.ASTIf.interpret(ASTIf.java:85)
at com.ibm.jscript.ASTTree.ASTTry.interpret(ASTTry.java:109)
at com.ibm.jscript.ASTTree.ASTProgram.interpret(ASTProgram.java:119)
at com.ibm.jscript.ASTTree.ASTProgram.interpretEx(ASTProgram.java:139)
at com.ibm.jscript.JSExpression._interpretExpression(JSExpression.java:435)</values>
<values>
at com.ibm.jscript.JSExpression.access$1(JSExpression.java:424)
at com.ibm.jscript.JSExpression$2.run(JSExpression.java:414)
at java.security.AccessController.doPrivileged(AccessController.java:284)
at com.ibm.jscript.JSExpression.interpretExpression(JSExpression.java:410)
at com.ibm.jscript.JSExpression.evaluateValue(JSExpression.java:251)
at com.ibm.jscript.JSExpression.evaluateValue(JSExpression.java:234)
at com.ibm.xsp.javascript.JavaScriptInterpreter.interpret(JavaScriptInterpreter.java:220)
at com.ibm.xsp.binding.javascript.JavaScriptMethodBinding.invoke(JavaScriptMethodBinding.java:111)
at com.ibm.xsp.component.UIViewRootEx.invokePhaseMethodBinding(UIViewRootEx.java:1705)
at com.ibm.xsp.controller.FacesControllerImpl.invokePhaseMethodBinding(FacesControllerImpl.java:444)
at com.ibm.xsp.controller.FacesControllerImpl.access$0(FacesControllerImpl.java:438)
at com.ibm.xsp.controller.FacesControllerImpl$</values>
<values>ViewPhaseListener.afterPhase(FacesControllerImpl.java:506)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:218)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:120)
at com.ibm.xsp.controller.FacesControllerImpl.render(FacesControllerImpl.java:264)
at com.ibm.xsp.webapp.FacesServlet.serviceView(FacesServlet.java:219)
at com.ibm.xsp.webapp.FacesServletEx.serviceView(FacesServletEx.java:193)
at com.ibm.xsp.webapp.FacesServlet.service(FacesServlet.java:154)
at com.ibm.xsp.webapp.FacesServletEx.service(FacesServletEx.java:137)
at com.ibm.xsp.webapp.DesignerFacesServlet.service(DesignerFacesServlet.java:86)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.invokeServlet(ComponentModule.java:538)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet(NSFComponentModule.java:1151)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$AdapterInvoker.invokeServl</values>
<values>et(ComponentModule.java:803)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$ServletInvoker.doService(ComponentModule.java:758)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.doService(ComponentModule.java:527)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService(NSFComponentModule.java:1135)
at com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:523)
at com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:352)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:304)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:261)
at com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:291)
Caused by: java.security.PrivilegedActionException: java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices
at java.security.AccessController</values>
<values>.doPrivileged(AccessController.java:255)
at com.sun.faces.config.ManagedBeanFactory.newInstance(ManagedBeanFactory.java:216)
... 51 more
Caused by: java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices
at java.beans.Beans.instantiate(Beans.java:194)
at java.beans.Beans.instantiate(Beans.java:75)
at com.sun.faces.config.ManagedBeanFactory$1.run(ManagedBeanFactory.java:222)
at java.security.AccessController.doPrivileged(AccessController.java:251)
... 52 more
</values>
</extendedDataElements>
<sourceComponentId component="Expeditor 6.2" componentIdType="ProductName" instanceId="" location="<server here>" locationType="Hostname" subComponent="com.sun.faces.application.ApplicationImpl" threadId="0" componentType="http://www.w3.org/2001/XMLSchema-instance"/>
<situation categoryName="ReportSituation">
<situationType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ReportSituation" reasoningScope="INTERNAL" reportCategory="LOG"/>
</situation>
</CommonBaseEvent>
As ever, penny for your thoughts.
Also, thank you all for your feedback. I'm sorry I've been away for a bit and neglected this question. I really would like to figure this out.
You didn't mention Project -> Clean so try that first.
I had once similar problem that was caused by an underscore in class or package name.
If the problem exists also for XPages then it's a a general build problem. This can occur at least when developers with different Designer and/or ExtLib versions modify the application. When I had this problem the only way to fix it was to create a new application and copy paste everything there. In our case the other developer never had the problem.
This is just silly. My src folder wasn't on the build path. That was causing all the issues.

Getting errors leasing tasks

When I try to lease tasks from a pull queue in my application, I get the error below. This didn't happen previously with my code, so something has changed. I suspect that it's a threading issue - these calls are made in a separate thread (created using ThreadManager.createThreadForCurrentRequest) - has that recently been disallowed?
uk.org.jaggard.myapp.BlahBlahBlahRunnable run: Exception leasing tasks. Already tried 0 times.
com.google.apphosting.api.ApiProxy$CancelledException: The API call taskqueue.QueryAndOwnTasks() was explicitly cancelled.
at com.google.apphosting.runtime.ApiProxyImpl.doSyncCall(ApiProxyImpl.java:218)
at com.google.apphosting.runtime.ApiProxyImpl.access$000(ApiProxyImpl.java:68)
at com.google.apphosting.runtime.ApiProxyImpl$1.run(ApiProxyImpl.java:182)
at com.google.apphosting.runtime.ApiProxyImpl$1.run(ApiProxyImpl.java:180)
at java.security.AccessController.doPrivileged(Native Method)
at com.google.apphosting.runtime.ApiProxyImpl.makeSyncCall(ApiProxyImpl.java:180)
at com.google.apphosting.runtime.ApiProxyImpl.makeSyncCall(ApiProxyImpl.java:68)
at com.google.appengine.tools.appstats.Recorder.makeSyncCall(Recorder.java:323)
at com.googlecode.objectify.cache.TriggerFutureHook.makeSyncCall(TriggerFutureHook.java:154)
at com.google.apphosting.api.ApiProxy.makeSyncCall(ApiProxy.java:105)
at com.google.appengine.api.taskqueue.QueueApiHelper.makeSyncCall(QueueApiHelper.java:44)
at com.google.appengine.api.taskqueue.QueueImpl.leaseTasksInternal(QueueImpl.java:709)
at com.google.appengine.api.taskqueue.QueueImpl.leaseTasks(QueueImpl.java:731)
at uk.org.jaggard.myapp.BlahBlahBlahRunnable.run(BlahBlahBlahRunnable.java:53)
at com.google.apphosting.runtime.ApiProxyImpl$CurrentRequestThreadFactory$1$1.run(ApiProxyImpl.java:997)
at java.security.AccessController.doPrivileged(Native Method)
at com.google.apphosting.runtime.ApiProxyImpl$CurrentRequestThreadFactory$1.run(ApiProxyImpl.java:994)
at java.lang.Thread.run(Thread.java:679)
at com.google.apphosting.runtime.ApiProxyImpl$CurrentRequestThreadFactory$2$1.run(ApiProxyImpl.java:1031)
I suspect the warnings in your application's logs will contain
"Thread was interrupted, throwing CancelledException."
Java's InterruptedException is discussed in
http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html
and the book "Java Concurrency in Practice".

Categories

Resources