[
https://issues.apache.org/jira/browse/QPID-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7535:
-----------------------------
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".
was:
If there is a thread trying to acquire the dispatcher lock whist 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".
> [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
> Fix For: qpid-java-6.2
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
