qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Harvey <p...@philharveyonline.com>
Subject Detecting potential Java deadlocks with JCarder
Date Fri, 06 Sep 2013 15:32:13 GMT
I want to let others know about some interesting and useful lock analysis
I've been doing.

I recently ran the Java systests with the JCarder [1] agent enabled.
 JCarder instruments the bytecode, allowing it to keep track of when locks
are acquired and released.  It uses this to detect whether locks are ever
taken in an order that would, given unlucky scheduling, result in deadlock.

Potential deadlocks are represented by GraphViz .dot files which can be
easily visualised to show the locks, threads and methods involved.

JCarder found several potential deadlocks in the Java client, which fall
into three categories:

1. Would only happen if the application used JMS "illegally", according to
the thread-safety section of the JMS spec.  I think we can ignore these.
2. Manifestations of QPID-4574 (close a session or consumer in one thread
while onMessage is sending a message).  I've modified the Jira's
description/comments accordingly.
3.  New potential deadlocks.  I've raised QPID-5117/8/9 for these.  Please
shout if you think any of these are in fact duplicates.

Note that JCarder cannot currently detect java.util.concurrent locks, which
are heavily used by the Broker, so it is certainly no silver bullet.

Nevertheless, I recommend that we use JCarder when testing changes that
affect the threading/locking of any of our Java projects.


[1] http://www.jcarder.org/

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message