Re: Deadlock [Fixed - we think!]
Re: Deadlock [Fixed - we think!]
- Subject: Re: Deadlock [Fixed - we think!]
- From: Chuck Hill <email@hidden>
- Date: Tue, 27 Nov 2007 10:02:24 -0800
On Nov 27, 2007, at 4:34 AM, Simon McLean wrote:
Hi All -
Many thanks to everyone for their help with my recent deadlock
issue. I think we may well have nailed it as we've managed 18 hours
now without a blip.
What was the problem?
Particular thanks goes to the authors of the
ScreamingEditingContext whose logging has been our saviour.
We do however have one issue that continues to scream:
!!! editing context being disposed with 1 locks. !!! Most recently
locked by: java.lang.Throwable at
com.clicktravel.plumbing.system.ScreamingEditingContext._trace
(ScreamingEditingContext.java:52) at
com.clicktravel.plumbing.system.ScreamingEditingContext.lock
(ScreamingEditingContext.java:113) at
com.webobjects.appserver.WOSession._awakeInContext(WOSession.java:
717) at com.webobjects.appserver.WOApplication.restoreSessionWithID
(WOApplication.java:1550) at
er.extensions.ERXApplication.restoreSessionWithID
(ERXApplication.java:1432) at
com.webobjects.appserver.WOAction.existingSession(WOAction.java:
164) at
com.clicktravel.plumbing.components.CTDirectAction.performActionNamed(
CTDirectAction.java:133) at
com.webobjects.appserver._private.WOActionRequestHandler._handleReques
t(WOActionRequestHandler.java:240) at
com.webobjects.appserver._private.WOActionRequestHandler.handleRequest
(WOActionRequestHandler.java:145) at
er.extensions.ERXDirectActionRequestHandler.handleRequest
(ERXDirectActionRequestHandler.java:82) at
com.webobjects.appserver.WOApplication.dispatchRequest
(WOApplication.java:1306) at
er.extensions.ERXApplication.dispatchRequest(ERXApplication.java:
1161) at com.webobjects.appserver._private.WOWorkerThread.runOnce
(WOWorkerThread.java:173) at
com.webobjects.appserver._private.WOWorkerThread.run
(WOWorkerThread.java:254) at java.lang.Thread.run(Thread.java:613)
I know exactly where this is coming from: session().terminate()
when a user logs out.
Actually, this is coming from sleep() when it is called after session
().terminate() is called. I sense a slight defect in WO. :-) I
will have to check and see if it is still in 5.4.
The question is should we be worried about it ?
I had done this for years and not noticed any bad things that I could
trace back to it. That said, I don't do this anymore. To terminate a
session, I use session().setTimeout(1); That will also make this
scream die away.
The source of the ScreamingEditingContext suggests binning an EC
with a lock on it is bad practice, so I guess we should tidy it up
but i'm a bit concerned about the inner-workings of WO and whether
overriding terminate() is a good thing. This fixes the problem:
public void terminate() {
this.defaultEditingContext().unlock(); // Not sure why WO doesn't
do this itself ?
super.terminate();
}
Can anyone see a problem with that ?
You should not need to unlock the default EC.
For reference, here is my terminate method:
public void terminate()
{
// Need to make sure this is unlocked so that editing
contexts nested in the defaultEditingContext
// don't hold locks on it when it gets disposed
synchronized (ecLockManager)
{
if (ecLockManager().isLocked())
{
try
{
ecLockManager().unlock();
}
catch (Throwable t)
{
// DANGEROUS: we *must* eat this exception or the
whole app might deadlock
NSLog.err.appendln("********** EXCEPTION in
WOSession.terminate() calling ecLockManager.unlock(): " + t);
}
}
}
super.terminate();
NSLog.out.appendln("Terminated session " + sessionID());
NSLog.out.appendln("Remaining active sessions: " +
WOApplication.application().activeSessionsCount());
}
--
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden