qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Greig" <robert.j.gr...@gmail.com>
Subject Re: Intermittent Test Failures [was: Re: M2 - let us try another "final" build]
Date Sun, 23 Sep 2007 21:57:07 GMT
On 22/09/2007, Robert Greig <robert.j.greig@gmail.com> wrote:
> I managed to get a threaddump and it shows yet another deadlock
> involving the dispatcher. Details are attached to QPID-589.

Looking at the deadlock, it occurs because during session close, it
sends Basic.Cancel for each consumer, and the Basic.Cancel-Ok handler
(on a separate thread) calls Dispatcher.rejectPending which in turn
tries to acquire the dispatcher lock. Sadly the dispatcher lock is
already held by dispatcher.run(). Dispatcher.run is trying to acquire
the messageDeliveryLock, which is already held by the close method is

I couldn't spot an obvious solution involving reordering of locks.
However it did occur to me that it was not necessary to send a
Basic.Cancel where we are about to close the entire session (AMQP

Does anyone disagree and think we have to send Basic.Cancel?

I have committed a change to the M2 branch so that it does not send
Basic.Cancel where the session is closing and so far on our continuous
build there have been no test failures or deadlocks. If it turns out
that someone knows why we must send Basic.Cancel then I will obviously
back out that change.


View raw message