[rabbitmq-discuss] to ack or not to ack? that is the question...

Thu Apr 15 22:29:09 BST 2010

Hi Jon,

Whether 'tis nobler in the client to suffer the tedium of constant redeliveries
or to take arms against the tide of poisoned messages and by acknowledging, end
them?

You've hit on the two major approaches to responsibility-transfer that AMQP
supports:

 - At most once, where acking is immediate, before processing, or where
   no-ack mode is used

 - At least once, where acking is delayed until after processing.

(You get exactly-once by setting expiry timers appropriately and using a
deduplication filter in conjunction with at-least-once.)

There's no point in acking immediately you receive a message: you may as well
use no-ack mode, which lets the server be more efficient internally besides
automatically "acknowledging" the outbound message as it hits the wire toward
the client. If you have acknowledgements enabled, it makes more sense to
acknowledge after processing the message. (If you're doing exactly-once, then
"processing" could simply entail making a note of the message in the
deduplication filter.)

With regard to not knowing the content/types of a message, we often find that
segregating message types onto separate queues makes good sense. It permits the
use of different acking policies, which are configured on a per-consumer basis.

Regards,
  Tony