So we added support for federated queues in RabbitMQ 3.2.0. This blog post explains what they're for and how to use them. Read the rest of this entry »
RabbitMQ is a very extensible message broker, allowing users to extend the server’s functionality by writing plugins. Many of the broker features are even shipped as plugins that come by default with the broker installation: the Management Plugin, or STOMP support, to name just a couple. While that’s pretty cool, the fact that plugins must be written in Erlang is sometimes a challenge. I decided to see if it was possible to write plugins in another language that targeted the Erlang Virtual Machine (EVM), and in this post I’ll share my progress.
In the last couple of months I’ve been paying attention to a new programming language called Elixir that targets the EVM, and in the last week it became immensely popular inside the Erlang community (and other circles) since Joe Armstrong, the father of Erlang, tried the language, and liked it very much. So I said, OK, lets give it a try.
RabbitMQ includes a bunch of cool new features. But in order to implement some of them we needed to change some things. So in this blog post I'm going to list some of those things in case you need to do anything about them. Read the rest of this entry »
I've written a plugin for RabbitMQ that adds support for the MQTT 3.1 protocol. MQ Telemetry Transport is a light-weight PUB/SUB protocol designed for resource-constrained devices and limited bandwidth situations, making it ideally suited to sensors and mobile devices. The implementation is a protocol adapter plugin, allowing MQTT clients to connect to a RabbitMQ broker simultaneously with clients implementing other protocols. We encourage projects that demand the combination of a low-overhead protocol on a robust, scalable broker with high reliability and enterprise features to consider this option. Read the rest of this entry »
Here at Rabbit HQ we've been enjoying "RabbitMQ in Action", the introduction to RabbitMQ and messaging. Part of the Manning series, the book is written by Jason Williams and Alvaro Videla, both well known for their many contributions to the Rabbit community.
Today we'd like to say thank-you to Jason and Alvaro. Thank-you Jason and Alvaro! You did an amazing job and infinite beers are on us.
But there's more... Manning have kindly offered a promotional discount of 37% to readers of this blog. All is revealed below, in a guest post by Jason Williams himself...
RabbitMQ in Action is here
Well, it's finally here. After 18 months of writing, re-writing and updating, RabbitMQ in Action is finished and in the flesh. It's hard to believe that when we started, RabbitMQ was at version 1.8.0 and now we're at 2.8.2. So much has changed in Rabbit that required rewrites of whole sections along the way, that it feels like we're really at 5 or 6.0. It's a testament to the Rabbit team members that helped us that the book kept pace with it all. So now that it's out why should you read it (besides the 37% discount code below)?
If you feel like you want a deeper understanding than the online tutorials offer, we wrote this for you. Whether it's figuring out clustering and mirrored queues, or just getting a better understanding of messaging fabrics (queues, bindings and routing exchanges, relays and federations.), our goal was to write the book we wished had existed when we started, and that we hope will help you. From the management console and API to building real world applications and plugins, we've tried to cover everything you need to get a good foundation of Rabbit under your belt…and hopefully that you can use as a desk reference too.
Lots of example code on Github to get you started
One thing we tried to focus on was using RabbitMQ to link together different applications written in completely different languages. That's one of the main reasons we wrote the examples in Python and PHP. However, we had two other reasons also:
1.) Python reads almost like pseudo-code and produces incredibly readable programs…which makes it an excellent teaching language. You can focus on what the example program's doing, without a lot of class declarations and boiler plate clouding up the works.
2.) There are a ton of books on messaging targeted at Java and the old-line enterprise brokers. We wanted to write something different... something that was easier to read and more accessible to people without any background in messaging. RabbitMQ in Action is very much a book for people of all languages and backgrounds. Writing in Python and PHP helped us do that (there's appendices on using Rabbit with Java and .NET too).
With that last one in mind, we’ve done something a little different than other Manning books…all of our examples are in a public repo on Github.
We did this so that if you feel like converting the examples into the language of your choice to help those like you, you can. As long as the license on your contribution is BSD, we'll merge in your pull requests and hopefully build a huge library of RabbitMQ examples that can help everyone. There are already Ruby versions of the examples merged in!
So if those aren't reasons enough to give RabbitMQ in Action a shot…how about a 37% discount just because you read this blog?
Save 37% on RabbitMQ in Action with Promotional Discount Code 12rmqb when you checkout at the Manning web site.
For quite a while here, at RabbitMQ headquarters, we were struggling to find a good way to expose messaging in a web browser. In the past we tried many things ranging from the old-and-famous JsonRPC plugin (which basically exposes AMQP via AJAX), to Rabbit-Socks (an attempt to create a generic protocol hub), to the management plugin (which can be used for basic things like sending and receiving messages from the browser).
Over time we've learned that the messaging on the web is very different to what we're used to. None of our attempts really addressed that, and it is likely that messaging on the web will not be a fully solved problem for some time yet.
That said, there is a simple thing RabbitMQ users keep on asking about, and although not perfect, it's far from the worst way do messaging in the browser: exposing STOMP through Websockets.
You have a queue in Rabbit. You have some clients consuming from that
queue. If you don't set a QoS setting at all (
Rabbit will push all the queue's messages to the clients as fast as
the network and the clients will allow. The consumers will balloon in
memory as they buffer all the messages in their own RAM. The queue may
appear empty if you ask Rabbit, but there may be millions of messages
unacknowledged as they sit in the clients, ready for processing by the
client application. If you add a new consumer, there are no messages
left in the queue to be sent to the new consumer. Messages are just
being buffered in the existing clients, and may be there for a long
time, even if there are other consumers that become available to
process such messages sooner. This is rather sub optimal.
So, the default QoS
prefetch setting gives clients an unlimited
buffer, and that can result in poor behaviour and performance. But
what should you set the QoS
prefetch buffer size to? The goal is to
keep the consumers saturated with work, but to minimise the client's
buffer size so that more messages stay in Rabbit's queue and are thus
available for new consumers or to just be sent out to consumers as
they become free. Read the rest of this entry »
Welcome back! Last time we talked about flow control and latency; today let's talk about how different features affect the performance we see. Here are some simple scenarios. As before, they're all variations on the theme of one publisher and one consumer publishing as fast as they can.