The best pilots possess the superior judgment to avoid situations
requiring their superior skills to survive
On Apr 29, 2009, at 1:05 PM, Dov Rosenberg wrote:
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/kenlists%40anderhome.com
This email sent to [email protected]
_______________________________________________
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]
