Good Decisions Come From Wisdom Wisdom comes from Experience Experience comes from Making Bad Decisions
On 4/29/09 12:58 PM, "Chuck Hill" <[email protected]> wrote: > > On Apr 29, 2009, at 6:49 AM, Miguel Arroz wrote: > >> Hi! >> >> This is a "Request for Experience" kind of email. :) > > Good judgement is the result of experience. Experience is the result > of bad judgement. > > Like that? > > > >> I'm having a really hard time to track down issue and I would like >> to know if any of you has already seen this symptoms, and have any >> clue of what might be going on. >> >> My problems is the following: occasionally (and it doesn't seem to >> depend on the load, as it occurs on weekdays during peak usage as >> well as weekends) a session will not expire after the defined 60 >> minutes, and it will exist forever. Apparently, it won't cause any >> problem to the app, besides locking down some WorkerThreads. >> >> I've done several thread dumps, including one as soon as I detected >> this (the session had about 62 minutes of idle time). The only thing >> weird I saw is something that, at first, I thought it was a >> consequence of the problem, whatever that was, but now I think it's >> tied to the cause, as I see anything else that might be causing this. >> >> 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) > 4. Dead lock in a request so it never terminates. You would see this > in the stack trace so I think we can discount it. > > You can override > public void saveSessionForContext(WOContext aContext) > in Application to log out when the session is saved. The only way I > now of to track this down is to (a) examine your code and (b) add > enough logging that you can look back in the log and see where a > session did not get checked in. > > You could probably do something clever like set a flag in the thread > and clear it in saveSessionForContext and throw at the end of dispatch > request if the flag was still set. > > > Chuck > _______________________________________________ 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]
