[rabbitmq-discuss] More detail on bug refusing publishes fixed in 2.8.3
simon at rabbitmq.com
Fri Aug 2 10:36:31 BST 2013
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.
> 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 :-)
More information about the rabbitmq-discuss