In your full production trace, is there an indication which thread has
the "<0xd50244e8>" lock?
I've debugged similar situations where threads were "blocked waiting
for monitor <0x.>" (getting java.sql.Connections, as it turned
out) -- identifying & examining the thread that had locked that
mo
> From: Robillard, Greg L [mailto:greg.l.robill...@lmco.com]
> Subject: RE: EXTERNAL: Re: Tomcat hung
> "http-8080-200" daemon prio=10 tid=0xcbca9800 nid=0xb5e waiting on condition
> [0xc5dbc000..0xc5dbcea0]
>java.lang.Thread.State: WAITING (parking)
> at
eentrantReadWriteLock$FairSync)
at java.util.concurrent.locks.LockSupport.park(Unknown Source)
I can include more if required.
-Original Message-
From: Pid [mailto:p...@pidster.com]
Sent: Wednesday, November 17, 2010 3:57 PM
To: Tomcat Users List
Subject: EXTERNAL: Re: Tomcat hung
On 17/11/2010 21:50, Robillard, Greg L
