Potentially helpful for other people down the road too, but we were battling with WOSession deadlocks in our app as well.
We are running a RESTful backend available to web clients, with some potentially taking up to half a minute while the request blocked on other systems which had a long response time. The front end calling this app was using AJAX requests, and the potential existed for a user to make several AJAX requests to the app causing them all to block on the first long request because the session was checked out. What we did was verify a request session, then store the important session values and immediately check the session back in. To get that to work though we had to make sure WOSession wasn't locking it's default editing context in awakeInContext, as at the end of the R-R loop in _sleepInContext it would attempt to unlock the session EC, which resulted in an illegalMonitorStateException, I presume because with the session checked back in it didn't own the lock any longer. All part of the concurrent request handling fun! :) On Jun 10, 2010, at 10:34 PM, Chuck Hill wrote: > > On Jun 10, 2010, at 1:31 PM, Ricardo J. Parada wrote: > >> >> On Jun 10, 2010, at 4:03 PM, Chuck Hill wrote: >> >>> Moving this to the correct list. >>> >> >> Thanks. >> >>> >>> On Jun 10, 2010, at 12:54 PM, Ricardo J. Parada wrote: >>> >>>> >>>> We have one app that we just turned on concurrent request handling >>>> and we seem to get a deadlock. But I'm not sure why or what to do >>>> to fix it. :-) >>>> This happens logging in to the application. >>>> >>>> I'm using WO 5.4.3 and Wonder revision 10715. >>>> >>>> Here's a stack trace of each thread (it looks like the deadlock is >>>> between WorkerThread13 and WorkerThread14: >>> >>> No, both of those threads are waiting for a session that other >>> threads have checked out (possibly the same thread). Either that >>> thread is takinga long time or the session did not get checked >>> back in. >>> >> >> When does the session get checked back in? I'm not familiar with >> that aspect of WO. > > At the end of the Request - Response loop, before the response is > returned to the browser. > > >> >> >>> Do you have any code the Session methods awake, sleep, or terminate? >>> >> >> I looked and the code in awake() is just setting a couple of i- >> vars. It doesn't seem to be doing much. But I'll look more >> carefully. >> >> >>> >>> Chuck >>> >>> >>>> >>>> >>>> Jun 10 10:14:34 PatientPortionPricer[2013] FATAL >>>> er.extensions.statistics.ERXStatisticsStore - Request is taking >>>> too long, possible deadlock: 300294 ms >>>> >>>> Request Thread Name: ERXStopWatchTimer >>>> >>>> Java2D Disposer: >>>> Thread[Java2D Disposer,10,main]: >>>> at java.lang.Object.wait(Native Method) >>>> at java.lang.ref.ReferenceQueue.remove(Unknown Source) >>>> at java.lang.ref.ReferenceQueue.remove(Unknown Source) >>>> at sun.java2d.Disposer.run(Unknown Source) >>>> at java.lang.Thread.run(Unknown Source) >>>> WorkerThread13: >>>> Thread[WorkerThread13,5,main]: >>>> at java.lang.Object.wait(Native Method) >>>> at java.lang.Object.wait(Unknown Source) >>>> at >>>> com >>>> .webobjects >>>> .appserver >>>> .WOSessionStore.checkOutSessionWithID(WOSessionStore.java:191) >>>> at >>>> com >>>> .webobjects >>>> .appserver.WOApplication.restoreSessionWithID(WOApplication.java: >>>> 1913) >>>> at >>>> er >>>> .extensions >>>> .appserver.ERXApplication.restoreSessionWithID(ERXApplication.java: >>>> 2215) >>>> at >>>> com >>>> .mpv >>>> .webapp >>>> .patientportionpricer >>>> .Application.restoreSessionWithID(Application.java:46) >>>> at >>>> com >>>> .webobjects >>>> .appserver >>>> ._private >>>> .WOComponentRequestHandler >>>> ._dispatchWithPreparedApplication(WOComponentRequestHandler.java: >>>> 324) >>>> at >>>> com >>>> .webobjects >>>> .appserver >>>> ._private >>>> .WOComponentRequestHandler >>>> ._handleRequest(WOComponentRequestHandler.java:369) >>>> at >>>> com >>>> .webobjects >>>> .appserver >>>> ._private >>>> .WOComponentRequestHandler >>>> .handleRequest(WOComponentRequestHandler.java:445) >>>> at >>>> er.ajax.AjaxRequestHandler.handleRequest(AjaxRequestHandler.java:17) >>>> at >>>> com >>>> .webobjects >>>> .appserver.WOApplication.dispatchRequest(WOApplication.java:1687) >>>> at >>>> er >>>> .extensions >>>> .appserver >>>> .ERXApplication.dispatchRequestImmediately(ERXApplication.java:1920) >>>> at >>>> er >>>> .extensions >>>> .appserver.ERXApplication.dispatchRequest(ERXApplication.java:1885) >>>> 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(Unknown Source) >>>> Session Timeout Thread: >>>> Thread[Session Timeout Thread,5,main]: >>>> at java.lang.Thread.sleep(Native Method) >>>> at com.webobjects.appserver.WOSessionStore >>>> $_SessionTimeoutManager.run(WOSessionStore.java:98) >>>> at java.lang.Thread.run(Unknown Source) >>>> WorkerThread14: >>>> Thread[WorkerThread14,5,main]: >>>> at java.lang.Object.wait(Native Method) >>>> at java.lang.Object.wait(Unknown Source) >>>> at >>>> com >>>> .webobjects >>>> .appserver >>>> .WOSessionStore.checkOutSessionWithID(WOSessionStore.java:191) >>>> at >>>> com >>>> .webobjects >>>> .appserver.WOApplication.restoreSessionWithID(WOApplication.java: >>>> 1913) >>>> at >>>> er >>>> .extensions >>>> .appserver.ERXApplication.restoreSessionWithID(ERXApplication.java: >>>> 2215) >>>> at >>>> com >>>> .mpv >>>> .webapp >>>> .patientportionpricer >>>> .Application.restoreSessionWithID(Application.java:46) >>>> at >>>> com >>>> .webobjects >>>> .appserver >>>> ._private >>>> .WOComponentRequestHandler >>>> ._dispatchWithPreparedApplication(WOComponentRequestHandler.java: >>>> 324) >>>> at >>>> com >>>> .webobjects >>>> .appserver >>>> ._private >>>> .WOComponentRequestHandler >>>> ._handleRequest(WOComponentRequestHandler.java:369) >>>> at >>>> com >>>> .webobjects >>>> .appserver >>>> ._private >>>> .WOComponentRequestHandler >>>> .handleRequest(WOComponentRequestHandler.java:445) >>>> at >>>> er.ajax.AjaxRequestHandler.handleRequest(AjaxRequestHandler.java:17) >>>> at >>>> com >>>> .webobjects >>>> .appserver.WOApplication.dispatchRequest(WOApplication.java:1687) >>>> at >>>> er >>>> .extensions >>>> .appserver >>>> .ERXApplication.dispatchRequestImmediately(ERXApplication.java:1920) >>>> at >>>> er >>>> .extensions >>>> .appserver.ERXApplication.dispatchRequest(ERXApplication.java:1885) >>>> >>>> >>>> Thanks, >>>> Ricardo >>>> >>> >>> -- >>> 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/products/practical_webobjects >>> >>> >>> >>> >>> >>> >>> >> > > -- > 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/products/practical_webobjects > > > > > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/blawson%40chellomedia.com > > This email sent to blaw...@chellomedia.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
