Hey Philip, Thanks for the analysis! I've been closely following your work. JCarder seems like a very useful tool. Given that we use multiple locks, there are many ways to get into deadlock situations which has made the current client untenable in some user environments. I will definitely use this tool in my future work.
Regards, Rajith On Fri, Sep 6, 2013 at 11:32 AM, Phil Harvey <[email protected]>wrote: > 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. > > Phil > > [1] http://www.jcarder.org/ >
