[rabbitmq-discuss] to ack or not to ack? that is the question...
tonyg at lshift.net
Thu Apr 15 22:29:09 BST 2010
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
You've hit on the two major approaches to responsibility-transfer that AMQP
- 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
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.
More information about the rabbitmq-discuss