Re: WOSessionStore deadlock
Re: WOSessionStore deadlock
- Subject: Re: WOSessionStore deadlock
- From: Dov Rosenberg <email@hidden>
- Date: Wed, 29 Apr 2009 13:05:19 -0400
- Thread-topic: WOSessionStore deadlock
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@hidden> 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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden