[ https://issues.apache.org/jira/browse/QPID-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15712756#comment-15712756 ]
ASF subversion and git services commented on QPID-7535: ------------------------------------------------------- Commit 1772250 from [~k-wall] in branch 'java/branches/6.1.x' [ https://svn.apache.org/r1772250 ] QPID-7535: [Java Client] Strengthen notification between threads holding dispatcher lock Merged from trunk with commandL svn merge -c 1770716 https://svn.apache.org/repos/asf/qpid/java/trunk > [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