qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-6374) [Java Client] Eliminate deadlocks by acquiring locks in a consistent order
Date Tue, 10 Feb 2015 11:59:36 GMT

    [ https://issues.apache.org/jira/browse/QPID-6374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14314065#comment-14314065
] 

ASF subversion and git services commented on QPID-6374:
-------------------------------------------------------

Commit 1658689 from [~godfrer] in branch 'qpid/trunk'
[ https://svn.apache.org/r1658689 ]

QPID-6374 : Always call exception listener from connection task pool, rather than from within
the failover mutex

> [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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message