[rabbitmq-discuss] Fw: high availability solutions?

[Michael Klishin]

2011/6/17 Matthew Sackman <matthew at rabbitmq.com>

>
> One approach would be that rather than (or in addition to) documenting
> features of AMQP, instead document use cases and how to solve them. In
> that context, it makes sense to say something along the lines of "if
> you're using a broker that doesn't support publisher confirms, then
> you'll have to use transactions here. But beware of the following
> problems with transactions: ...; many of these problems can be solved by
> using publisher confirms instead, but currently this extension is only
> implemented by ...".
>

This is the approach we are taking with amqp gem.

After thinking about it for a bit, we will do the following:

 * As far as functionality and test suite organization goes, simply do what
the most recent version of the Java client does. Broker version checking may
be considered.
 * In documentation, focus on how Publisher Confirms and message
acknowledgements can be used to
   accomplish what people may first consider using transactions for.
Transactions will be mentioned, too.
 * We already have a guide dedicated to RabbitMQ versions, so whenever tx.*
is dropped, that document will be updated.


> Frankly, the more painful it is to use
> such ancient versions, the more pressure should be exterted on such
> distributions to update their versions of Rabbit[0]. Our clients stopped
> supporting 0-8 when we introduced broker support for 0-9-1.
>
I'm actually
> a little surprised we still support 0-8 in the broker.
>
>
Many popular clients/versions of clients still support 0.8 only. I even
happen to use
0.8 producers and 0.9.1 consumers because upgrading all applications at the
same time
wasn't an option. So I hope AMQP 0.8 support in RabbitMQ will stay around
for a few more
releases.
-- 
MK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110617/58e21877/attachment.htm>