[rabbitmq-discuss] Consequences of not ACK-ing
tonygarnockjones+rabbitmq at gmail.com
Sat Feb 11 14:00:24 GMT 2012
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.
tonygarnockjones at gmail.com
More information about the rabbitmq-discuss