Re: Cant reenter deployed application after an uncaught exception.
Re: Cant reenter deployed application after an uncaught exception.
- Subject: Re: Cant reenter deployed application after an uncaught exception.
- From: Art Isbell <email@hidden>
- Date: Mon, 26 Jun 2006 11:12:33 -1000
On Jun 26, 2006, at 6:19 AM, Zac Konopa wrote:
Both excellent questions.
But what you need are excellent answers :-)
As to the first I'm afraid I don't have an exception backtrace.
Since is a "deployment" build it's hiding the back trace
automatically. I'm doing the research to figure out how to turn
that off today.
<http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/jdb.html>
might help. You'd need to add the java arguments "-Xdebug -
Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n" in
JavaMonitor and invoke the debugger on a hung instance by entering
the following at a shell prompt on the application server:
jdb -attach 8000
"where all" should dump a stack trace of all threads.
Or you could send a SIGQUIT signal to the hung process, but if
you're deployed under Tiger Server, launchd may swallow the stack
trace dump. This can be fixed by adding StandardOutPath and
StandardErrorPath keys with appropriate file path values to /System/
Library/LaunchDaemons/com.apple.womonitor.plist.
JavaMonitor has not been able to restart the app so your editing
context deadlock exception sounds quite plausible. I'm not
familiar with this though can you explain a little more?
If the process is deadlocked, the direct action that JavaMonitor
sends to the instance to ask it to quit won't be executed due to the
deadlock. The deadlock might occur because a thread is waiting for a
resource locked by second thread which is waiting for resource locked
by the first thread.
As for locking and unlocking an editing context, here goes. I
follow the following guidelines whenever I'm working with an
editing context.
You don't mention whether you're locking/unlocking the Session's
default editing context. If so, don't because it's being locked/
unlocked automatically.
You also don't mention whether you're using a shared editing
context. If so, it doesn't need to be locked/unlocked only when
using certain methods (as documented).
If you're creating your own editing contexts, they always need to be
locked/unlocked correctly. Many recommend MultiECLockManager
(<http://www.wocode.com/WOCode/Files/MultiECLockManager.java>) for
doing this flawlessly.
If you access a database context directly, it also needs to be
locked/unlocked.
So it's easy to get into a deadlocking situation if one isn't
scrupulous about locking and unlocking shared resources.
Now that I think about it I like this deadlocked ec idea a lot
because I have essentially no exception handling at this point, and
I happen to know what is throwing the exception and that it would
happen before the ec was unlocked. However what would cause this
to change from a dev build to a deploy build?
Nothing but chance. Deadlocking occurs because of a race condition
among threads that is usually difficult to reproduce. It's much more
likely during deployment because the deployed processes run far
longer than most development processes.
This is a rather complex topic for some of us to grasp confidently.
So someone please correct any of my misconceptions.
Aloha,
Art
_______________________________________________
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