[rabbitmq-discuss] detecting publish failure across restart

[Matthew Sackman]

On Mon, May 31, 2010 at 02:21:57PM +0100, David Wragg wrote:
> The workaroud is to use the transaction support in AMQP: Start a
> transaction (with Channel.txSelect), do some publishes on the channel,
> and then commit the transaction (with Channel.txCommit).  If the commit
> completes successfully, you know that the publishes have taken place on
> the server.

Note that doing this converts the semantics from "at most once" to "at
least once". I.e. before, with mandatory set, you will not have to deal
with duplicates - if the error (due to not being able to route the msg
to a queue) gets lost (network issue or client/server crashing) then the
published message is lost, but you don't run the risk of duplicates -
even in the case where you republish if you get the delivery failure.

With transactions, there's the possibility that the commit_ok message
gets lost as it goes back from the server to the client. In that case
you have no choice but to assume in the client that the server has not
accepted responsibility for the messages in the transaction and thus you
must republish yourself. However, if it's just the commit_ok message
that got lost then you'll be publishing the same messages more than once
and thus you need to account for the possibility of duplicates when
receiving messages.

Matthew