For a while people have looked for ways of implementing delayed
messaging with RabbitMQ. So far the accepted solution was to use a mix
of message TTL and
Dead Letter Exchanges as proposed
by James Carr
here. Since
a while we have thought to offer an out-of-the-box solution for this,
and these past month we had the time to implement it as a
plugin. Enter
RabbitMQ Delayed Message Plugin.

"How much memory is my queue using?" That's an easy question to ask, and a somewhat more complicated one to answer. RabbitMQ 3.4 gives you a clearer view of how queues use memory. This blog post talks a bit about that, and also explains queue memory use in general.
Read the rest of this entry »

One of the goals for RabbitMQ 3.3 was that you should be able to find bottlenecks in running systems more easily. Older versions of RabbitMQ let you see that you were rate-limited but didn't easily let you see why. In this blog post we'll talk through some of the new performance indicators in version 3.3.
Read the rest of this entry »

What? Another "breaking things" post? Well, yes, but hopefully this should be less to deal with than the previous one. But there are enough slightly incompatible changes in RabbitMQ 3.3.0 that it's worth listing them here.

In this blog post we are going to address the problem of controlling the access to a particular resource in a distributed system.
The technique for solving this problem is well know in computer science, it's called Semaphore and it was invented by Dijkstra in 1965
in his paper called "Cooperating Sequential Processes". We are going to see how to implement it using AMQP's building blocks, like consumers,
producers and queues.

Different services in our architecture will require a certain amount of resources for operation, whether these resources are CPUs, RAM or disk space, we need to make sure we have enough of them. If we don't put limits on how many resources our servers are going to use, at some point we will be in trouble. This happens with your database if it runs out of file system space, your media storage if you fill it with images and never move them somewhere else, or your JVM if it runs out of RAM. Even your back up solution will be a problem if you don't have a policy for expiring/deleting old backups. Well, queues are no exception. We have to make sure that our application won't allow the queues to grow for ever. We need to have some strategy in place to delete/evict/migrate old messages.

With RabbitMQ 3.2.0 we introduced Consumer Priorities which not surprisingly allows us to set priorities for our consumers. This provides us with a bit of control over how RabbitMQ will deliver messages to consumers in order to obtain a different kind of scheduling that might be beneficial for our application.