[rabbitmq-discuss] More detail on bug refusing publishes fixed in 2.8.3

[Simon MacMullen]

On 01/08/2013 6:36PM, asternb at gmail.com wrote:
> I'm looking for more detail on a bug fixed in 2.8.3. The only
> description in the release notes is "queues with many busy consumers
> could refuse to accept publishes until empty"
> (http://www.rabbitmq.com/release-notes/README-2.8.3.txt). Could someone
> link me to the bug with detail in a tracker or copy that info here?

We don't have a public bug tracker I'm afraid.

The bug was that queues always prioritised sending messages to consumers 
over accepting messages from publishers. Normally this was OK, since the 
limiting factor in sending messages to consumers was either how fast 
they could be streamed off disc, how fast they were coming in, or how 
fast they could be pushed onto the network, thus giving the queue CPU 
time to do other things.

However, if the queue had a lot of consumers (typically at least 
hundreds), and all those consumers were active, then the queue could get 
into a state where it was CPU-bound - at which point it would then fail 
to accept publishes at all until empty.

> With
> that bug, does the broker block connections similar to flow control?

Before RabbitMQ 2.8.0 messages would back up indefinitely in the broker 
before getting to the queue - so the symptom of this bug would be a 
sudden spike in memory use (possibly leading to the memory alarm going 
off). In 2.8.0 to 2.8.2 the broker would put the publishers into flow 
control - normally flow control should flick on and off rapidly to 
restrict the publishing rate, but in this case flow control would stay 
on and the publishing rate would drop to 0.

The bug was fixed in 2.8.3; now queues give equal priority to accepting 
and delivering messages.

Of course, many other bugs have also been fixed since then so as ever 
you are advised to upgrade :-)

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, Pivotal