[rabbitmq-discuss] Consequences of not ACK-ing

[Tony Garnock-Jones]

Hi Paul,

On 11 February 2012 08:35, Bell, Paul M. <pbell at syncsort.com> wrote:
> I came across something that is, at first blush, a fly in the ointment. Specifically, I read that if a consumer doesn't ACK (and assuming no auto-ack), then the broker will NOT deliver another message to that consumer, until it does ACK the previous message.

This is only true if you've used Basic.Qos to limit the number of
outstanding messages the broker is willing to offer. For instance,
setting the prefetch count to 1 will give the behaviour you describe.
If, on the other hand, you don't issue a Basic.Qos command at all, the
prefetch count will be unlimited, and the broker will stream messages
to connected consumers until the TCP buffers at the sending side fill
up, without regard for ACKs, delayed or otherwise.

Regards,
  Tony
-- 
Tony Garnock-Jones
tonygarnockjones at gmail.com
http://homepages.kcbbs.gen.nz/tonyg/