On Dec 1, 2008, at 5:13 PM, Mike Schrag wrote:
This bug happens when multiple requests for a session come in
before the first request completes (Ajax on the page can cause
this) and the first request calls terminate() on the session (e.g.
from a log out link or in response to an exception during request
processing). The session terminates properly, but the threads for
the other queued requests for the now terminated sessions are
stuck. This prevents the app from restarting under wotaskd control
(other than force quitting it). An example trace from one such
stuck thread (highly mutilated, not my fault):
Are you kidding me? How has this one survived this long?
It might be newish. I don't think I saw it until 5.3, maybe slightly
earlier.
Why doesn't terminate check in the session?
It does check in the session, but because it has terminated, the
request that is blocked on the session checkout never gets unblocked.
Won't a terminated session .notify() the TimoutEntry?? That's
asinine. This is cruising for a Wonder fix, I think.
I really doubt that you could do this. I took the easier, if far less
elegant route, of setting the session timeout to a few seconds. That
way any queued requests pass through the RR loop. To make this a
little "safer", I also null the user and do other cleanup on the
session so that any further requests will just get an error page or a
login request.
Chuck
--
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 ([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]
