Re: WO instance locks up and won't die.
Re: WO instance locks up and won't die.
- Subject: Re: WO instance locks up and won't die.
- From: Chuck Hill <email@hidden>
- Date: Wed, 19 Nov 2003 21:31:42 -0800
Hi Denis,
At 01:29 PM 20/11/2003 +1300, Denis Stanton wrote:
>Hi Chuck
>
>Thank you for your support, again
>
You're quite welcome.
>On Wednesday, November 19, 2003, at 05:07 PM, Chuck Hill wrote:
>
>> It sounds as if your are deadlocking. Two common causes of this are
>> unbalanced locks to editing contexts (or other EO objects) and
>> exceptions
>> in your code triggering bugs in WO that result in checked out sessions
>> not getting checked back in.
>
>I'm only using the defaultEditingContext in my components (excluding
>direct actions). I don't lock or unlock any ECs. It is quite possible
>that the "stuck" sessions have encountered a null pointer exception. I
>did not expect this would result in a zombie session (by that I just
>mean a session that does not work, but does not die. I have a vague
>idea that "zombie" may be a term that has a special meaning to some )
>
A null pointer exception shoulnd't cause a session to become immortal, but
it has in past versions. This has been a particular problem when the
exception was raised in a direct action. There have been various fixes
posted that revolve around wrapping DirectAction.performAction in a
try...catch block so that the exception does not go any higher. I recall a
recent posting by someone (Lenny?) saying that this no longer worked for
all cases. I don't recall if that was 5.2.1 or 5.2.2. They also posted a
work around. Max Muller also posted a query about deadlocks with the
finalizer thread. Do you do anything in Session.terminate or
session.finalize?
>>> I start a second instance and they're happy, but if I tell the first
>>> instance to refuse new sessions it never dies. In fact sometimes the
>>> session count increases despite the setting.
>>>
>> This can happen if there are direct action requests that specify the
>> instance number.
>
>Excellent. That would explain the increasing count. I have some
>direct actions that serve up iCal files so that I can use iCal to
>monitor certain events in my app.
Interesting!
>iCal subscribes and keeps checking
>back every 15 minutes. The subscription URLs would contain the
>instance number except where I manually removed it because it seemed to
>me to be a bad thing to specify an instance in a direct action URL
>
My solution to that was to catch these, strip off the instance number, and
return a redirect. All with out creating a session. Direct actions can
reference sessions and session data. That is why WO inserts the instance
number when it generates a DA URL.
>>> You would expect that the
>>> session count would drop to zero as each times out.
>> Deadlock could explain this, as could sessions not getting checked
>> back in.
>
>So how does a deadlock get to give up?
>
There is no timeout so it pretty much lives up to it name. The only two
solutions are to prevent deadlock and to detect it and terminate the app
abuptly. I believe there are frameworks in Project WOnder that do the
later. Sepuku and Harikiri or something like that.
>I throw and catch an exception
>on every save, and the catch includes
> defaultEditingContext().revert();
>I thought that would throw out the attempted change and allow the user
>to try again. I'm obviously not doing enough.
>
The problem is bugs in the WO code that do not appropriate catch and handle
exceptions. These can result in a session not getting checked back in and
/ or an editing context not getting unlocked. On the next reference to the
locked session or EC your app just stops unless it processes requests
concurrently. In the latter case it keeps going on. For a while...
Concurrent dispatch is a crutch not a solution for this problem.
>>> Selecting stop does not close the instance. Restarting the computer
>>> does though.
>>>
>> Ya gotta worry when that doesn't work! ;-)
>
>I had to talk my client through exactly this yesterday. She was sure
>she had restarted the Mac after Safari froze and yet "it comes up with
>the chart displayed exactly as before". In other words, the Mac
>restarts, opens Safari, select the page (it is not the home page) and
>even navigates to the same customer data.
>
>I politely said this was not likely. The explanation was that pressing
>the On/off button, (which is conveniently placed above the CD drive on
>a G4-with-shiny-front-cover, so it looks like the CD eject button, but
>that's a different problem) - pressing the on/off button puts the
>computer to sleep, or awakens it. It does not necessarily restart,
>though how the new user knows the difference is beyond me. What she
>needed was press-and-hold-for-a-very-long-time-until-it-goes-bong
>
Chuckle.
>>> I don't know what could be causing this or how to trace it.
>>> I'm using WebObject 5.2.1 on Mac OS X 10.2.8. 1 GB RAM. Total number
>>> of client computers that could be accessing my app = 6 (yes, six)
>>>
>> Are you locking your editing contexts? Do you see any exceptions or
>> other unusual messages in the app log? Search the archives here or
>> at Omni for 'deadlock', lots of reading there. You should be able to
>> quickly turn up how to get a thread dump for your OS. That is the best
>> way to diagnose what is wrong.
>
>No, I'm not locking any EC. I use only
>session().defaultEditingContext, except in the Direct Actions.
>
You really ought to lock them in direct actions too, but if you create one
per call to a direct action that is not the cause of the deadlock (if, in
fact, that is what is happening). It is sounding more like a session is
not getting checked back in due to an exception. Have you overridden
handle... in Application? If so, make sure that each one can NOT throw an
exception. WO really does not like that:
public WOResponse handleException(Exception anException,
WOContext aContext) {
try {
// your exception handling code here
} catch (Throwable t) {
// We're in deep trouble here, see if super can help
try {
return super.handleException(anException, aContext);
} catch (Throwable t) {
// OK, this is really not good, suicide time
Runtime.getRuntime().exit(1);
}
}
}
>I better add Thread Dump to my reading list. Thank you
>
It is a handy tool to have.
Chuck
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.