Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
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
-
None
Description
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".