Java client deadlock issues

[Rajith Attapattu <ra...@gmail.com>]

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-subscribe@qpid.apache.org