Hi Maik, This can also indicate some other things too: - session did not get checked in (app threw OutOfMemory, sleep() threw an exception) - previous request for this session is still running (deadlock, waiting, infinite loop) - 2+ requests for the same session in rapid sequence where the first terminates the session
Chuck On 2012-10-19, at 4:00 AM, Maik Musall wrote: > Hi, > > I recently discovered what may be responsible for frequent deadlocks of an > application here. In the "jstack -l" output, I see almost all threads waiting > on a single ReentrantLock, and this thread is what holds that lock: > > > "WorkerThread4" prio=5 tid=103bc9000 nid=0x132caf000 in Object.wait() > [132cae000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <22711d098> (a > com.webobjects.appserver.WOSessionStore$TimeoutEntry) > at java.lang.Object.wait(Object.java:485) > at > com.webobjects.appserver.WOSessionStore.checkOutSessionWithID(WOSessionStore.java:191) > - locked <22711d098> (a > com.webobjects.appserver.WOSessionStore$TimeoutEntry) > at > com.webobjects.appserver.WOApplication.restoreSessionWithID(WOApplication.java:1913) > at > er.extensions.appserver.ERXApplication.restoreSessionWithID(ERXApplication.java:2440) > at > er.extensions.appserver.ERXComponentRequestHandler._dispatchWithPreparedApplication(ERXComponentRequestHandler.java:260) > at > er.extensions.appserver.ERXComponentRequestHandler._handleRequest(ERXComponentRequestHandler.java:302) > at > er.extensions.appserver.ERXComponentRequestHandler.handleRequest(ERXComponentRequestHandler.java:377) > at > com.webobjects.appserver.WOApplication.dispatchRequest(WOApplication.java:1687) > at > er.extensions.appserver.ERXApplication.dispatchRequestImmediately(ERXApplication.java:2139) > at > er.extensions.appserver.ERXApplication.dispatchRequest(ERXApplication.java:2104) > at > com.webobjects.appserver._private.WOWorkerThread.runOnce(WOWorkerThread.java:144) > at > com.webobjects.appserver._private.WOWorkerThread.run(WOWorkerThread.java:226) > at java.lang.Thread.run(Thread.java:680) > > Locked ownable synchronizers: > - <20ce7bbc0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > > > Now, ERXApplication.restoreSessionWithID contains an interesting call to > useSessionStoreDeadlockDetection(), but this detection only works in single > threaded mode. I'm afraid I can't afford to switch off concurrent requests > even for a testing period in production. > > I'm looking for someone with experience regarding this problem. The doc for > that method mentions that it could help "to find cases when a session is > checked out twice in a single RR-loop, which will lead to a session store > lockup." Since I cannot switch on this detection, what in your experience > could lead to that happening? > > Thanks > Maik > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net > > This email sent to [email protected] -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/gvc/practical_webobjects Global Village Consulting ranks 13th in 2012 in BIV's Top 100 Fastest Growing Companies in B.C! Global Village Consulting ranks 76th in 24th annual PROFIT 200 ranking of Canada’s Fastest-Growing Companies by PROFIT Magazine! _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
