tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat thread dump analysis
Date Wed, 08 May 2013 17:33:11 GMT
Hash: SHA256


On 5/8/13 11:25 AM, Caldarale, Charles R wrote:
>> From: Charles Richard [] 
>> Subject: Re: Tomcat thread dump analysis
>> Here is a full thread dump
> Which again shows no Tomcat involvement in the locking hang.


At least it confirms OP is actually running Tomcat, which wasn't
evident from the first stack trace.

Charles, please understand that what you have presented is a stack
trace, not a thread dump: the difference is that a thread dump is a
stack trace for every live thread in the JVM (which can show
deadlocks) and you have provided only a single stack trace which
cannot show a deadlock (it can only show that the thread is waiting on
some condition).

To demonstrate deadlock, you need to be able to see the condition
being awaited in one thread, a lock held in another thread, and then
the opposite scenario in another thread (or a single thread running
into its own locks). Your stack trace does not show that the thread
already holds the lock being awaited at the top of the stack trace.

It is entirely possible that both Spring and Terrecotta attempt to
synchronize on the same object (HttpSession) and that the thread is
deadlocking on itself. If this is trivially-repeatable every time
Terrecotta attempts to do whatever it is doing (hard to tell...
Hibernate is executing a SQL query which ... uses the session?!?),
then perhaps you have identified the problem and the Spring
configuration to synchronize on a session attribute rather than the
session itself will fix the problem.

On the other hand, if the problem is different and yet you have
arrived at your "Spring + Terrecotta = deadlock" conclusion due to
treating Google as a consultant, then you may be barking up the wrong

Sorry: we like to get enough facts before we tell you a) what the
problem is and b) how to fix it rather than just saying "I Googled for
'terra cotta deadlock' and someone said that if you use Spring, you
get deadlocks" and telling you to go away. Instead, we'd rather help
you fix your actual problem and educate you at the same time.

> It would appear that logic in your application threads has either 
> created a deadlock, or failed to unlock something before
> returning,

That's a tall order unless native code is involved, I believe. Though
I don't have much experience with the java.lang.concurrent package...

> or something else entirely (e.g, broken network causing grief with 
> Terracotta's distributed caching).  If it's a deadlock, you need
> to examine the entire thread dump (all threads) and look for a
> call stack that isn't like the others but holds the lock everyone
> else is waiting for.  If it's simply a failure to unlock somewhere,
> you will likely have to do a thorough code review to find it.  You
> will most likely need Terracotta's help here, since it's their code
> waiting on the lock.


Start with finding out what Terrecotta is trying to lock on: if it's
not the session, then you know you're entirely wrong about the cause.

Also, knowing whether the thread is deadlocking itself versus another
thread deadlocking with it is a very important piece of information to

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message