Yes, thank you for clarifying that Matthias.<br><br><div class="gmail_quote">On Sun, Jul 26, 2009 at 4:38 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@lshift.net">matthias@lshift.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Charles,<div class="im"><br>
<br>
charles woerner wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So in the case of competing consumers taking messages from a rabbitmq<br>
broker cluster it sounds like once-and-only-once delivery is somewhat<br>
up to the application to implement by arranging for each message to<br>
be delivered to redundant queues (ie. 2 separate queues with similar<br>
bindings residing on different hosts), then coordinate among your<br>
consumers to ensure once-and-only-once delivery using a database or<br>
simply to make your workflow idempotent with respect to the duplicate<br>
messages.<br>
</blockquote>
<br></div>
Exactly-once requires coordination between consumers, or idempotency,<br>
even when there is just a single queue. The consumer, broker or network<br>
may die during the transmission of the ack for a message, thus causing<br>
retransmission of the message (which the consumer has already seen and<br>
processed) at a later point.<br>
<br>
Once that issue has been addressed in a system, the introduction of redundant queues doesn't present any new challenges.<br>
<br>
<br>
Regards,<br><font color="#888888">
<br>
Matthias.<br>
</font></blockquote></div><br>