RabbitMQ needs more and better documentation. (And who doesn’t?) In particular, we need more and better introductory material that introduces the reader to various basic concepts, explains why they’re important, and motivates him or her to keep reading and learn more about RabbitMQ. Here’s a cut at Chapter 1 of that introduction. Your comments are welcome, and Chapters 2 and 3 will follow soon. (You probably already know all of this, but a surprising number of people don’t. This introduction is for them.)
Arriving in RabbitMQ 2.1.1, is support for bindings between exchanges. This is an extension of the AMQP specification and making use of this feature will (currently) result in your application only functioning with RabbitMQ, and not the myriad of other AMQP 0-9-1 broker implementations out there. However, this extension brings a massive increase to the expressivity and flexibility of routing topologies, and solves some scalability issues at the same time.
Normal bindings allow exchanges to be bound to queues: messages published to an exchange will, provided the various criteria of the exchange and its bindings are met, pass through the various bindings and be appended to the queue at the end of each binding. That’s fine for a lot of use cases, but there’s very little flexibility there: it’s always just one hop – the message being published to one exchange, with one set of bindings, and consequently one possible set of destinations. If you need something more flexible then you’d have to resort to publishing the same message multiple times. With exchange-to-exchange bindings, a message published once, can flow through any number of exchanges, with different types, and vastly more sophisticated routing topologies than previously possible.
Recently, Michael Bridgen and I implemented a bridge to connect the RabbitMQ broker with applications using 0MQ for messaging.
Here it is: http://github.com/rabbitmq/rmq-0mq
So: What kind of benefit the users can get by using both products in parallel?
I am setting up my old MacBook, reclaimed from my housemate, to be usable for the programmings.
The RabbitMQ team has been working with Martin Sustrik to provide code and documentation for using RabbitMQ and ZeroMQ together. Why is this a good idea? Because the broker and brokerless approaches are complementary. We’ll be posting more about this as the codebase evolves. This post is introductory and can be seen as commentary on Ilya Grigorik’s excellent introduction to ZeroMQ and the InfoQ summary of Ilya’s article.
Among other things, lately we have been preoccupied with improving RabbitMQ’s routing performance. In particular we have looked into speeding up topic exchanges by using a few well-known algorithms as well as some other tricks. We were able to reach solutions many times faster than our current implementation.
The previously mentioned management plugin is now in a state where it’s worth looking at and testing. In order to make this easy, I’ve made a special once-only binary release just for the management plugin (in future we’ll make binary releases of it just like the other plugins). Download all the .ez files from here and install them as described here, then let us know what you think. (Update 2010-09-22: Note that the plugins referenced in this blog post are for version 2.0.0 of RabbitMQ. We’ve now released 2.1.0 - for this and subsequent versions you can get the management plugin from here).
Some three and a half years after we launched RabbitMQ, we have this week released RabbitMQ 2.0.
This means some big changes. The most important of these is our new Scalable Storage Engine. RabbitMQ has always provided persistence for failure recovery. But now, you can happily push data into Rabbit regardless of how much data is already stored, and you don’t need to worry about slow consumers disrupting processing. As the demands on your application grow, Rabbit can scale with you, in a stable, reliable way.
Before introducing RabbitMQ 2.0, let me reiterate that as Rabbit evolves you can count on the same high level of commitment to you as a customer or end user, regardless of whether you are a large enterprise, or a next-gen start-up, or an open source community. As always, get in touch if you need help or commercial support.
For a long time the management and monitoring capabilities built into RabbitMQ have consisted of rabbitmqctl. While it’s a reasonable tool for management (assuming you like the command line), rabbitmqctl has never been very powerful as a monitoring tool. So we’re going to build something better.
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.
Support for AMQP’s
basic.reject just landed on default. It’s taken this long because we couldn’t agree on a single set of semantics that followed the specification, was actually useful, and wasn’t too complicated to implement.
And welcome to the all-new RabbitMQ blog!