[rabbitmq-discuss] Fw: high availability solutions?

[Matthew Sackman]

On Fri, Jun 17, 2011 at 02:59:39PM +0400, Michael Klishin wrote:
> Does it mean client maintainers should discourage transaction use by
> focusing on publisher confirms and message acknowledgements? It just
> so happens that I am in the process of expanding Ruby amqp gem
> documentation on transactions and their relation to publisher confirms
> & message acknowledgements. I am not sure what to do now.

There problem with AMQP transactions as they're defined is that they're
essentially useless once you have publisher confirms.

The only compelling use case is if you had a client that wanted to
receive a message, transform it, and republish it as one action. In that
case, wrapping that lot in a transaction makes sense. However, what
you'll immediately notice is that the transaction precludes you from
publishing to a different broker than you received from.

Instead, you should publish with confirms, wait for the confirm, and
then ack the message you received. This allows you to use different
brokers, and allows you to pipeline actions, substantially increasing
performance.

Yes, in the event of a failure of a client, you could end up with
duplicates - the ack could be lost and so that initial message will be
requeued and delivered. But in the event of client (and broker)
failures, there's always the chance of duplicates anyway, and even
transactions do not actually solve this (for one thing, the
implementation of transactions in Rabbit is _not_ atomic).

We would encourage all 3rd party clients to work to support the
extensions to AMQP 0-9-1 that we add. That does not mean that we
recommend you remove functionality that we remove - you can certainly
implement a superset of the functionality. But normally when we add and
remove features, it's because there is some fundamental deficiency that
needs to be addressed and so it's obviously helpful if 3rd party clients
are aware of that.

I hope that helps,

Matthew