[rabbitmq-discuss] Fw: high availability solutions?

[Matthew Sackman]

On Fri, Jun 17, 2011 at 03:29:01PM +0400, Michael Klishin wrote:
> That said, as a client library maintainer, I have a number of concerns:
> 
> * Should I explicitly discourage people from using tx.* class?

I think that documenting the deficiencies of transactions is worthwhile.
Whether that goes as far as actively telling people to not use them is
unclear, but certainly as far as Rabbit is concerned, we're likely to
make that decision for people ;)

> * How do I justify even more protocol fragmentation to library users?

Well this is certainly an issue. StormMQ, OpenAMQ and apparently the
Java QPid all claim to support 0-9-1, though in reality, the ambiguity
in the specification and the subsequently different readings of the spec
pretty much guarantee that application authors will, in all but the most
trivial of cases, need to be aware of which broker they're writing for.
In many ways, it's broadly comparable to the SQL 92 standard. Sadly, it
doesn't look as if this is going to improve either, for reasons beyond
our control.

> * What do I do with my test suite that covers tx.* operations? I can
> add conditions that check for RabbitMQ versions but that makes me
> think of Internet Explorer 6 and you can imagine what kind of thought
> that is.

Indeed. I don't really have a good answer here. Have you tried running
your test suite against other 0-9-1 implementations? I would be a little
surprised if it passes entirely which really means you're going to have
to do some degree of broker detection anyway.

> However, I want amqp gem to have excellent documentation that also
> helps library users understand when to use what features and why. The
> prospect of tx.* removal from that standpoint is a problem for me. We
> already have to explain people what AMQP 0.8 to 0.9.1 move means and
> why they cannot use stock Ubuntu packages. Adding one more note that
> "oh, and if you happen to use transactions, please use RabbitMQ server
> < 2.6.0" is possible but I can imagine it won't reassure readers in
> RabbitMQ stability and maturity.

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 ...".

The fact that some distributions still ship utterly ancient versions of
Rabbit is a different problem. 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.

Matthew

[0] At the other end of the scale, we have the opposite problem where,
for example, Homebrew goes and updates their version of Erlang so
rapidly that they break both Rabbit and Riak because it takes us a while
to get versions out that can cope with the changes introduced in, for
example, R14B03 (though that has not been the only version of Erlang
which has caused us problems).