[
https://issues.apache.org/jira/browse/QPID-6374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-6374.
------------------------------
Resolution: Fixed
> [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
>
> Attachments: client_deadlock_3.diff
>
>
> 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]
