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
Production, as of yet, strangely, I have not been able to create this problem
testing.
Here is the top of the stack without a profiler.
2010-10-04 10:35:50
Full thread dump Java HotSpot(TM) Server VM (10.0-b19 mixed mode):
"Attach Listener" daemon prio=10 tid=0x08170400 nid=0x716b waiting on co
