[
https://issues.apache.org/jira/browse/QPID-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7535:
-----------------------------
Fix Version/s: (was: qpid-java-broker-7.0.0)
qpid-java-client-0-x-6.3.0
> [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.1.1, qpid-java-client-0-x-6.3.0
>
>
> 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.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
