As of v3.7.0 Milestone 8, RabbitMQ ships with a brand new set of CLI tools (rabbitmqctl, rabbitmq-plugins, and more), reworked from the ground-up. We had a few goals with this project.

Version 4.0 of the RabbitMQ Java Client brings support for runtime metrics. This can be especially useful to know how a client application is behaving. Let's see how to enable metrics collection and how to monitor those metrics on JMX or even inside a Spring Boot application.

The RabbitMQ team is happy to announce the release of version 4.0 of the RabbitMQ Java Client. This new release does not introduce any breaking changes and comes with a bunch of interesting new features.

We are pleased to announce the immediate availability of RabbitMQ 3.6.0, a new version of the broker that comes packed with lot of new features. Before we go on, you can obtain it here: /docs/download.

This release brings many improvements in broker features, development environment for our contributors, and security. Let's take a look at some of the most significant ones.

In order to prevent fast publishers from overflowing the broker with more messages than it can handle at any particular moment, RabbitMQ implements an internal mechanism called credit flow that will be used by the various systems inside RabbitMQ to throttle down publishers, while allowing the message consumers to catch up. In this blog post we are going to see how credit flow works, and what we can do to tune its configuration for an optimal behaviour.

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.

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.

I warn you before we start: this is another wordy blog post about performance-ish changes in RabbitMQ 3.3. Still with us? Good.

So in the previous post I mentioned "a new feature which I'll talk about in a future blog post". That feature is consumer bias.

Well, we got the bad news out of the way yesterday, so today let's talk about (some of) the good news: some types of publishing and consuming are now a great deal faster, especially in clusters.