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
