Re: WOSessionStore deadlock
Re: WOSessionStore deadlock
- Subject: Re: WOSessionStore deadlock
- From: Kieran Kelleher <email@hidden>
- Date: Thu, 30 Apr 2009 18:15:52 -0400
As per other message earlier, concurrent handling of request now off
and ERXSessionStoreDeadlock detection is now ON ...... so we will see.
On Apr 30, 2009, at 12:38 AM, Chuck Hill wrote:
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?
Standard on every project - "I never leave home without it"
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.
Well, I already had try/catch/finally with the call to super in
finally. However I just now wrapped all of that in a try/catch
log.error in case an error was being throw from super.sleep/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