For generating JVM dump on Windows, <ctrl> <break> and <ctrl> <scroll lock> work
equally well.
Mike
Scott Stirling wrote:
> Does Orion do more than check a timeout value for deadlock detection? Some
> servers just assume a deadlock if a method call takes too long. That's the
> simplest type of deadlock detection.
>
> Anyway, I use <Ctrl><Pause/Break> to get a stack dump on Windows (i.e, I
> don't think <Ctrl><ScrLk will work, will it?). The <Ctrl><\> combo also
> works on both Windows and UNIX. A real stack dump from the JVM will tell you
> more about what K-5 and E-6 are, and show you a call stack for the two
> threads that are deadlocked.
>
> So did the Orion server print out that deadlock info, or was that somehow
> percolated from the JVM? That's interesting. You're extremely lucky if the
> JVM detects a deadlock for you, which it sometimes does. Having spent many
> hours wading through stack dumps from problem apps and buggy JVMs, I think
> if you have the exact deadlock info like you do below (thread A is locking
> resource x and thread B is locking resource y, etc.) you're pretty darn
> fortunate. Lots of times that deadlocks occur, JVMs don't detect it.
>
> Disable JIT when before you try to catch this in a stack dump, or else you
> won't be able to see the line numbers in the stack traces.
>
> Scott Stirling
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Clark
> Sent: Tuesday, November 14, 2000 2:23 PM
> To: Orion-Interest
> Subject: Re: DeadlockException
>
> Ah, nothing quite like two threads in a deadly embrace! At least the
> server detects the deadlock and prints some useful debug for deadlock
> situations.
>
> Try generating a VM dump using
>
> Windows: <Ctrl> <Scroll Lock>
> *nix : kill -QUIT <server process id>
>
> In general, you're looking for a thread in the MW state that has
> already locked a monitor on which some other MW thread is trying to
> synchronize.
>
> In your case, thread 5 and thread 6 are deadlocked, both waiting to
> synchronize on a monitor held by the other. The stack trace
> information may help you determine where the deadlock is occurring.
>
> Mike
>
> --- Thomas Hertz <[EMAIL PROTECTED]> wrote:
> >
> > Hello,
> >
> > AC> Does anyone know what the following error means?
> >
> > AC> 11/14/00 10:51 PM Error in bean
> > com.netregistry.aucom.accounting.BillingAccount:
> > AC> Error in ejbPassivate
> > AC> com.evermind.server.DeadlockException: Deadlock detected: thread
> > 11 is waiting for
> > AC> resource entity 1003 held by thread 11
> >
> > AC> Any ideas on how to track it down?
> >
> > Just ten minutes before I read this message I encountered the same
> > error in my application. (1.4.4)
> >
> > com.evermind.server.rmi.OrionRemoteException: Transaction was rolled
> > back:
> > com.evermind.server.DeadlockException: thread 6 is waiting for
> > resource entity K-5
> > held by thread 5 in transaction [Transaction
> > 4d:1:0:0:0:0:0:0:0:e2:0:e2:d4:67:89:da]
> > who is waiting for resource entity E-6 held by thread 6 in
> > transaction [
> > Transaction 4a:1:0:0:0:0:0:0:0:e2:0:e2:d4:67:89:93]; nested exception
> > is:
> >
> > I am not quite sure what that means exactly. Can anybody help us?
> >
> > Thanks in advance,
> >
> > /Thomas
--
Mike Clark
Clarkware Consulting
Enterprise Java Architecture, Design, Development
http://www.clarkware.com
