Re: WOSessionStore deadlock
Re: WOSessionStore deadlock
- Subject: Re: WOSessionStore deadlock
- From: Chuck Hill <email@hidden>
- Date: Wed, 29 Apr 2009 21:38:46 -0700
On Apr 29, 2009, at 6:47 PM, Kieran Kelleher wrote:
It was a subtle question looking for insight :-) ..... some
pointers on what logging traps to put in place to catch the root
cause next time.
It is a pity that ERX session store deadlock only works with
concurrent req handling off.
I think something can be done. You are using Wonder?
I use 5.3.3, but does 5.4.X have some definite fixes for the session
store deadlock problem?
Not that I know of.
Meanwhile, for next release, I wrapped the complete contents of
Session terminate and sleep with a try/catch and log.error so as not
to throw anything from those. I guess I need to do he same for
DirectAction subclasses performActionNamed(...)?
I think that try...finally is a better pattern for sleep and terminate.
performActionNamed can, I think, pass the exception to the handler in
WOApplication. It has been a while since I did battle with this, it
is kind of foggy.
Chuck
On Apr 29, 2009, at 8:55 PM, Chuck Hill wrote:
On Apr 29, 2009, at 2:39 PM, Kieran Kelleher wrote:
Funny ... I got my first session deadlock in a long while just a
few minutes ago... had to kill the instance. Stack trace here:
http://67.78.26.66:81/~kieran/misc/deadlock-5183.txt
WO 5.3.3 BTW
Was there a question there, or just a gloat? :-P
It looks like the same problem as Miguel's.
Chuck
On Apr 29, 2009, at 1:05 PM, Guido Neitzer wrote:
On Apr 29, 2009, at 9:58 AM, Chuck Hill wrote:
I have 3 threads like this, all waiting on the same monitor:
"WorkerThread15" prio=5 tid=0x08995400 nid=0x8995600 in
Object.wait() [0xbf0dd000..0xbf0ddb80]
at java.lang.Object.wait(Native Method)
- waiting on <0x34000548> (a
com.webobjects.appserver.WOSessionStore$TimeoutEntry)
at java.lang.Object.wait(Object.java:474)
at
com
.webobjects
.appserver
.WOSessionStore.checkOutSessionWithID(WOSessionStore.java:207)
- locked <0x34000548> (a
com.webobjects.appserver.WOSessionStore$TimeoutEntry)
at
com
.webobjects
.appserver
.WOApplication.restoreSessionWithID(WOApplication.java:1546)
at
er
.extensions
.appserver
.ERXApplication.restoreSessionWithID(ERXApplication.java:2028)
...
I noticed Wonder has something to detect session store
deadlocks, but it works only when concurrent requests are off,
and we have that feature turned on.
What can be causing a session to be checked out, but not
checked in again?
Bad coding? :-P
I can think of only four causes:
1. Exception thrown from sleep().
2. Exception thrown from terminate() (not 100% sure of that)
3. Exception thrown from WODirectAction.performAction() (though
I am pretty sure this was fixed in WO 5.3)
It wasn't. At least not for everything.
cug
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Chuck Hill Senior Consultant / VP Development
Come to WOWODC'09 in San Fran this June!
http://www.wocommunity.org/wowodc09/
--
Chuck Hill Senior Consultant / VP Development
Come to WOWODC'09 in San Fran this June!
http://www.wocommunity.org/wowodc09/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden