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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com

This email sent to [email protected]

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net

This email sent to [email protected]


--
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to