RabbitMQ and AMQP 0-9-1
Since the beginning, RabbitMQ has implemented the 0-8 version of the AMQP specification. This was the first publicly-available version, but there's been plenty of development since then. In particular, we've wanted to support the 0-9-1 version of AMQP for a while now.
For around the last year we've maintained a 0-9-1-supporting branch of the broker and clients in Mercurial, and interested users have been running that version as it matures. Well, it's finally mature and we're now merging the 0-9-1 support into the default branch. This means it'll be in the next release.
At this point, you're probably wondering what the differences are between 0-8 and 0-9-1. Well, the good news is that the differences are not huge, and are entirely sensible. 0-9-1 mostly cleans up the 0-8 spec, explaining more clearly how the broker and clients are expected to behave in certain edge cases, and removing a whole load of ambiguity and half (or less) thought out features from 0-8.
In fact, if you're running 1.8.0 or later, you're already running a broker with most of the semantic changes from 0-9-1. But the wire protocol has changed a bit too, so it matters whether you're speaking 0-9-1 or 0-8.
For the Java and Erlang clients, we're intending to simply switch to supporting AMQP 0-9-1 exclusively in the next release. The .NET library already supports multiple protocols, so we're adding 0-9-1 as another option (and making it the default). For the broker we're going to support both AMQP 0-9-1 and AMQP 0-8. For any other client libraries we encourage you to speak to the library developer 
This means that this time it's safe to upgrade just your broker, or your broker and all your clients, but it's not safe to upgrade your clients without upgrading your broker!
Thank you for your attention.
Tags: broker, clients, New Features, standards
August 4th, 2010 at 5:39 pm
[...] RabbitMQ » Blog Archive » RabbitMQ and AMQP 0-9-1 - Messaging that just works rabbitmq.com/blog/2010/08/04/rabbitmq-and-amqp-0-9-1/ – view page – cached RabbitMQ is a complete and highly reliable enterprise messaging system based on the emerging AMQP standard Tweets about this link [...]
August 4th, 2010 at 11:18 pm
Perhaps this is a stupid question but why is AMQP not backwards compatible like any other modern protocol? Surely this is easy to do with optional headers and feature negotiation. This is how websockets works.
August 5th, 2010 at 8:03 am
AMQP is backwards compatible in the sense that client and server negotiate a version of the protocol to use. The situation is not hugely different from HTTP in that regard.
August 27th, 2010 at 12:06 pm
[...] Native support for multi-protocol messaging delivering better interoperability and more [...]
August 30th, 2010 at 4:18 pm
Please make the Java Client backwards compatible to 0-8. The Java Client internals have support for multiple protocols, it's only a matter of using them and/or exposing them through the ConnectionFactory.
Thanks!
October 10th, 2010 at 3:29 am
Hi,
With RabbitMQ, I have to achieve is a faster consumption of each message. The scenario is like this:
I have to send emails/SMSes to different people after consuming the messages internally. I want to just post a message and consume it faster by having multiple consumers ready. The message should be consumed only by one consumer…
Should I make a no. of consumers using a shared rabbitmq queue in which each consumer consumes the message posted on the exchange, deletes it from the queue and then after passes that message to a new thread for processing ?
But having a single queue might hamper the performance.
Is there any other way which can cater my requirement ? what do you suggest?