[rabbitmq-discuss] Consequences of not ACK-ing

[Bell, Paul M.]

Thank you, both.

That's quite a relief!

-Paul

________________________________________
From: tonygarnockjones at gmail.com [tonygarnockjones at gmail.com] On Behalf Of Tony Garnock-Jones [tonygarnockjones+rabbitmq at gmail.com]
Sent: Saturday, February 11, 2012 9:00 AM
To: Bell, Paul M.
Cc: RabbitMQ List
Subject: Re: [rabbitmq-discuss] Consequences of not ACK-ing

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/



ATTENTION: -----

The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other  confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.