qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Wall (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (QPID-7535) [Java Client] Strengthen notification between threads holding dispatcher lock
Date Thu, 01 Dec 2016 19:01:58 GMT

     [ https://issues.apache.org/jira/browse/QPID-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Keith Wall closed QPID-7535.
    Resolution: Fixed

> [Java Client] Strengthen notification between threads holding dispatcher lock
> -----------------------------------------------------------------------------
>                 Key: QPID-7535
>                 URL: https://issues.apache.org/jira/browse/QPID-7535
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Client
>    Affects Versions: 0.32, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, qpid-java-6.0.3,
qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1
>            Reporter: Alex Rudyy
>            Assignee: Alex Rudyy
>             Fix For: qpid-java-6.2, qpid-java-6.1.1
> If there is a thread trying to acquire the dispatcher lock whilst connection is being
stopped, it might  be never notified if a dispatcher thread receives the notification.
> I think the following scenario is susceptible for the issue:
> 1) Application is trying to recover the session in a special "receiver thread" which
is blocked whilst trying to acquire the dispatcher lock in AMQSession#recover->AMQSession$Dispatcher#recover.
(The same applies to session rollback)
> 2) Dispatcher thread is trying to deliver another message and is waiting for the dispatcher
lock in AMQSession$Dispatcher#dispatchMessage
> 3) Main thread in a call to Connection#stop  acquired the  dispatcher lock as part of
AMQSession$Dispatcher#setConnectionStopped and invokes _lock.notify().
> 3.1) The dispatcher thread receives the notification, wakes up, checks that "connection
stopped" flag is set to "true" and continue to wait. The "receiver thread" does not receive
the notification in this case, as "dispatcher thread" does not broadcast "notify". It looks
like there is a possibility for "a dead lock" here.
> Replacing "notify" with "notifyAll" should avoid running into the scenario described
above, as both "dispatcher thread" and "receiver thread" would be notified. Even if "dispatcher
thread" is notified first, the "receiver thread" would resume its execution after releasing
the lock by the "dispatcher thread".

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message