Rob Godfrey created QPID-6374:
---------------------------------

             Summary: [Java Client] Eliminate deadlocks by acquiring locks in a 
consistent order
                 Key: QPID-6374
                 URL: https://issues.apache.org/jira/browse/QPID-6374
             Project: Qpid
          Issue Type: Bug
          Components: Java Client
            Reporter: Rob Godfrey
            Assignee: Rob Godfrey
             Fix For: 0.31


A number of JIRAs exist relating to deadlocks in the Java client.

Deadlocks can generally be avoided if locks are always acquired in the same 
order however the Java client threading model can make this hard.

Two locks which in combination cause particular issues are the 
messageDeliveryLock and the failoverMutex.

The semantic purpose of the messageDeliveryLock is to meet the requirements of 
JMS that session.close(), connection.close() and consumer.close() block while 
the application is receiving a message in onMessage() or from receive().  The 
lock should only be acquired from an application thread or from the onMessage 
dispatcher thread - it should not be held by a thread acting on behalf of 
processing caused by io processing (e.g. the broker closing the session or 
connection).  The lock is session specific.

The semantic purpose of the failover mutex is to ensure that application 
actions which cause state change at the broker can are not engaged in while 
failover is occurring.  The lock is connection wide.  In general the lock 
should only be held by application threads, except for when failover is 
occurring, in which case the thread managing failover will hold the lock.

Since messageDeliveryLock has a narrower scope (session) than the failoverMutex 
(which is connection scoped) it makes sense to ensure that the 
messageDeliveryLock is always acquired first.  Changing this ordering where 
necessary, and removing and path where the messageDeliveryLock can be acquired 
by a non-application thread will greatly reduce the number of deadlocks seen.

Other deadlocks can be eliminated by removing the failoverMutex being acquired 
by threads acting on behalf of io processing, and by only holding the 
sessionCreationLock when setting the closed state or when actually creating a 
session.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to