[ 
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
(v6.3.4#6332)

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

Reply via email to