[rabbitmq-discuss] RabbitMQ blocking issue
Daniel Buchko
dbuchko at vmware.com
Tue Feb 26 19:12:35 GMT 2013
Matthias, could you please send Nokia a bug tracking number for reference purposes?
Thanks,
Dan
-----Original Message-----
From: Matthias Radestock [mailto:matthias at rabbitmq.com]
Sent: Saturday, February 23, 2013 8:29 AM
To: Konar Peter (Nokia-LC/Chicago)
Cc: Daniel Buchko; Carroll James (Nokia-LC/Malvern); Hancock Craig (Nokia-LC/Chicago); Venus Justin (Nokia-LC/Chicago); Yu Jerry.3 (Nokia-LC/Alpharetta); Lieber Dick (Nokia-LC/Chicago); Johnson Anthony (Nokia-LC/Alpharetta); Mccuiston Mitchell (Nokia-LC/Chicago); rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] RabbitMQ blocking issue
Peter,
On 21/02/13 17:26, Matthias Radestock wrote:
> After staring at the code for a couple of days I have identified and
> fixed one scenarios in which a connection could end up in the state
> you are seeing. It happens only after an illegal sequence of
> channel.close followed by basic.publish on the same channel, and only
> during a very narrow window in conjunction with flow control. So I
> doubt this is the cause, but it would still be worth giving that fix a
> try, just to rule out that scenario. I will send you a patch by private email.
After staring at the code some more, it turns out that there is a
*legal* sequence of AMQP commands that triggers the bug: a bunch of basic.publish commands followed by a channel.close, followed by a basic.publish on *another* channel.
The precise conditions are very intricate and highly timing sensitive, which explains why we have not seen any prior reports of this even though the bug was introduced nearly a year ago, in 2.8.0.
The patch I sent you fixes the problem and will appear in the next RabbitMQ bugfix release.
Thank you very much for the detailed reports and all the effort you invested in helping us track this down.
Regards,
Matthias.
More information about the rabbitmq-discuss
mailing list