Am 01.05.2009 um 04:12 schrieb Kieran Kelleher:
More good news ...... a side-effect of using ERX session store
deadlock detection and/or concurrent req handling=false is that
there are no CLOSE_WAITS and there are *no* threads blocked on
com.webobjects.appserver.WOSessionStore.checkOutSessionWithID(...),
not a single one in both of the instances that report these errors.
Yeah, it's a bit mis-named, since you get an exception right before
the double-checkout happens. So it's not checked-out and thus no
deadlock. In that regard, it's more "prevention".
Wonder normally gives me a detailed context information such as
previous page history and the exact component (actuallt nested
component tree) that was invoked to cause the error, but it seems
SessionInfo does not call that utility method
(ERXApplication#extraInformationForExceptionInContext(exception,
context)) .... I am going to try adding that to get the full picture
and redeploying.
Have fun... however, as you didn't actually set the session and it
hasn't restored the page, this util probably won't help...
It's been a while since I needed this, but:
- I normally implement ERXComponentActionRedirector.Restorable on my
pages so I get an easy URL for logging
- I did log both the context url and the restorable url
- if you know the page and the restore state, you can call it up and
look at the source and most likely, you will find the context id
- I still did a lot of debugging
Cheers, Anjo
_______________________________________________
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]
