tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Tomcat thread dump analysis
Date Wed, 08 May 2013 17:33:11 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Chuck,

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

+1

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
tree.

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.

+1

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
have.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRioxWAAoJEBzwKT+lPKRYz2AQAKbMT6qRh1oKvKdgBEUe1fJl
yqgyB0JOkb9pZ42P2bVovJJtO5A15tWw8NigEbKc+CwJMv9rgOzqRY7y30oih9mK
yhu5C/sEFDPlPPzt0H5CT3YFqVOoJMpstmgFBA0FBLKEaqmzdc61WIohQqJmv2J6
2z3vNvmH1xBucEqgOrOEn8mp9rbaOHVmQtf6Zh1QaxhBzA0CREnnwz0FvFEhklGx
rlpwkQafjcKjCCP6eaiurtZJtv4S0hJQJSOmLQKBdm3DY/dRokeN/ROnxn3DpqfX
e2JP4eAC2NYmKHwhXY3SOviK5Ha9NSB1fbBGSPSPQrjQ2In3UccYs6CENKOKUa68
0WwONHAw/OY0MzCJ6M9cZicX9XhNDNeRUzYlkORQpeAloM5w7Tp9q5fKo3iabFcC
NwuWN5O5H5TZ2MSH7UHV9Kf0EA1Zk7Howi2Ea2zV4EnzutdgM5yxq//ow8LTcOdi
ED376ckgSMgfV/b8u2tfJ1M9bD5WjD8v+kVbu+ErYzuM6i28iAGN7wrfgO+/Zn2S
BuQgcEq/3usUXwnQ5IBAYpVF5DAKv/GeAaV+C8Ft+mb+jgo00Hb7Eqn5eY/w6CL/
1DM0mgmfcHTlSP4JK5noV73Eip2LmxdPwDFvNBkIiRPq5Av+FSIfIKclJu/piMQ/
d0SCj26GbqSEIOYVUYX7
=3SsJ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message