qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Smith" <rupertlssm...@googlemail.com>
Subject Re: Intermittent Test Failures [was: Re: M2 - let us try another "final" build]
Date Mon, 24 Sep 2007 10:33:21 GMT
Hi Robert,

Thanks for your patches. Does this mean that the tests in the client module
are now passing consistently, or do we still have more to do?

On 23/09/2007, Robert Greig <robert.j.greig@gmail.com> wrote:
> 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
> AMQSession.
> 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
> channel).
> 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.
> RG

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message