• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: WOSessionStore deadlock
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • Follow-Ups:
    • Re: WOSessionStore deadlock
      • From: Ken Anderson <email@hidden>
References: 
 >Re: WOSessionStore deadlock (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: WOSessionStore deadlock
  • Next by Date: Re: Migrating Data from a temporary table into another editing context
  • Previous by thread: Re: WOSessionStore deadlock
  • Next by thread: Re: WOSessionStore deadlock
  • Index(es):
    • Date
    • Thread