Hi All, The Java client code (more specifically the JMS layer) has locking at several layers and across multiple objects which makes it very hard to impose an order. This has been quite evident from the numerous deadlock issues we've had in the past.
Fixing the current issues (QPID-3214 & QPID-3216) may not be trivial and theoretically there can be more issues lying dormant. For example QPID-3216 is triggered by a recent commit http://svn.apache.org/viewvc?view=revision&revision=1092510 Looking at the code, you could see that certain actions (like closing a session) takes multiple locks. The same action can trigger more actions that may grab multiple locks in an arbitrary order (ex QPID-3216). Some of these locks are often leaked across objects complicating matters further - see AMQConnection.getFailoverMutex() and AMQSesion.getMessageDeliveryLock() I am also concerned about the performance implications of our locking strategy, especially on the consumer side. I'd like to hear some thoughts/suggestions about possible solutions. I am keen to see if we can fix this problem at a more general level rather than just tinkering to fix QPID-3214 & QPID-3216. Regards, Rajith --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
