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: Denis Stanton <email@hidden>
- Date: Thu, 20 Nov 2003 13:29:02 +1300
Hi Chuck
Thank you for your support, again
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 )
>> 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. 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
>> 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? 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.
>> 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
>> 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 diagnos
> what
> is wrong.
No, I'm not locking any EC. I use only
session().defaultEditingContext, except in the Direct Actions.
I better add Thread Dump to my reading list. Thank you
Denis Stanton
email@hidden
Home: (09) 533 0391
mobile: 021 1433622
_______________________________________________
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.