[rabbitmq-discuss] Acks versus Publisher confirms

Tue May 10 11:15:38 BST 2011

On 10/05/11 11:01, Simone wrote:
> Ok so I get publisher confirms have to do with messages getting from 
> the publisher to the broker, while acks concern the link from the 
> broker to the consumer, correct?
>
> With strongest delivery warranty I mean to make sure that once a 
> message has been published by a publisher it is going to reach all of 
> the consumers supposed to be receiving it.
>
> Therefore to achieve this sort of thing without using transactions I 
> have to use both publisher confirms and consumer acks, right? Just 
> trying to get a better understanding at how this works.
If you want a "once and only once" QoS, as opposed to a "at least once", 
then you'll need to deal with duplicates.

If you use publisher acks, then, when you receive the publisher ack from 
the broker you know the message has reached the server ok. However, if 
the server crashes, then it's possible the message did reach the server 
ok, but you didn't get the ack back before the server died.

If, on recovery, you resend any messages that you didn't receive 
publisher acks for, there is a possibility of duplicate messages on the 
server.

Similarly with consuming messages, if you ack messages from the consumer 
once they have been consumed, then if the server crashes after a message 
has been consumed but before the ack for that message is processed on 
the server, on recovery of the server the message may be redelivered.

if you build your message consumption logic to be idempotent (i.e. no 
harm comes in processing the same message twice), you can get an 
"effective" once and only once QoS. This may be hard or easy depending 
on your application semantics.
>
> Thanks
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110510/32219ec3/attachment.htm>