Archive for the 'New Features' Category

How to Monitor Authentication Attempts

March 1, 2021 by Diana Parra Corbacho

We have been constantly improving the monitoring capabilities that are built into RabbitMQ since shipping native Prometheus support in 3.8.0. Monitoring the broker and its clients is critically important for detecting issues before they affect the rest of the environment and, eventually, the end users.

RabbitMQ 3.8.10 exposes client authentication attempts metrics via both the Prometheus endpoint and the HTTP API.


RabbitMQ Kubernetes Operator reaches 1.0

November 17, 2020 by Yaron Parasol

We are pleased to announce that the RabbitMQ Operator for Kubernetes is now generally available. The RabbitMQ Operator makes it easy to provision and manage RabbitMQ clusters consistently on any certified Kubernetes distribution. Operators inform the Kubernetes container orchestration system how to provision and control specific applications. The Kubernetes (hereafter K8s) Operator pattern is a way to extend the K8s API and state management to include the provisioning and management of custom resources – resources not provided in a default K8s deployment. In this post, we’ll discuss how the Operator enables the K8s system to control a RabbitMQ cluster.


RabbitMQ Gets an HA Upgrade

April 20, 2020 by Jack Vanlightly

This is the first part of a series on quorum queues, our new replicated queue type. We’ll be covering everything from what quorum queues are, to hardware requirements, migration from mirrored queues and best practices.

Introducing Quorum Queues

Mirrored queues, also known as HA queues have been the de facto option for years when requiring extra data safety guarantees for your messages. Quorum queues are the next generation of replicated queue that aim to replace most use cases for mirrored queues and are available from the 3.8 release and onward.

In this blog series we’re going to cover the following:


RabbitMQ 3.8 Release Overview

November 11, 2019 by Jack Vanlightly

RabbitMQ 3.8 has just been released and has some major new features which focus on reliability, operations, and observability.

You can find the new 3.8 release on the GitHub releases page which includes information about what is included in the release as well as various installation assets. See our upgrade guide for more information about upgrading to 3.8.0.

Our team dedicates this release to Joe Armstrong, the creator of Erlang. Joe’s work in the fields of concurrent and distributed systems benefits RabbitMQ to this day. Equally importantly, Joe was a rare example of a brilliant engineer who was also very humble and kind.

Let’s take a quick look at the new features in this release.


Simplifying rolling upgrades between minor versions with feature flags

April 23, 2019 by Jean-Sébastien Pédron

In this post we will cover feature flags, a new subsystem in RabbitMQ 3.8. Feature flags will allow a rolling cluster upgrade to the next minor version, without requiring all nodes to be stopped before upgrading.


RabbitMQ Java Client Metrics with Micrometer and Datadog

April 10, 2018 by Arnaud Cogoluègnes

In this post we’ll cover how the RabbitMQ Java client library gathers runtime metrics and sends them to monitoring systems like JMX and Datadog.


New Configuration Format in RabbitMQ 3.7

February 22, 2018 by Michael Klishin

In this post we’ll cover a new configuration format available in RabbitMQ 3.7.0.


Peer Discovery Subsystem in RabbitMQ 3.7

February 18, 2018 by Michael Klishin

In this blog post we’re going to take a closer look at a new subsystem introduced in RabbitMQ 3.7.0.


What's New in RabbitMQ 3.7

February 5, 2018 by Michael Klishin

After over 1 year in the works, RabbitMQ 3.7.0 has quietly shipped right before the start of the holiday season. The release was heavily inspired by the community feedback on 3.6.x. In this post we’d like to cover some of the highlights in this release.


New Reactive Client for RabbitMQ HTTP API

October 18, 2017 by Arnaud Cogoluègnes

The RabbitMQ team is happy to announce the release of version 2.0 of HOP, RabbitMQ HTTP API client for Java and other JVM languages. This new release introduce a new reactive client based on Spring Framework 5.0 WebFlux.


RabbitMQ Java Client 5.0 is Released

September 29, 2017 by Arnaud Cogoluègnes

The RabbitMQ team is happy to announce the release of version 5.0 of the RabbitMQ Java Client. This new release is now based on Java 8 and comes with a bunch of interesting new features.


Brand new rabbitmqctl in 3.7.0

December 15, 2016 by Daniil Fedotov

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.


Metrics support in RabbitMQ Java Client 4.0

November 30, 2016 by Arnaud Cogoluègnes

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.


RabbitMQ Java Client 4.0 is released

November 24, 2016 by Arnaud Cogoluègnes

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.


What's new in RabbitMQ 3.6.0

December 28, 2015 by Alvaro Videla

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:

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.


Scheduling Messages with RabbitMQ

April 16, 2015 by Alvaro Videla

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.


Understanding memory use with RabbitMQ 3.4

October 30, 2014 by Simon MacMullen

“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.


Finding bottlenecks with RabbitMQ 3.3

April 14, 2014 by Simon MacMullen

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.


Consumer Bias in RabbitMQ 3.3

April 10, 2014 by Simon MacMullen

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.


An end to synchrony: performance improvements in 3.3

April 3, 2014 by Simon MacMullen

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.


Breaking things with RabbitMQ 3.3

April 2, 2014 by Simon MacMullen

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.


Preventing Unbounded Buffers with RabbitMQ

January 23, 2014 by Alvaro Videla

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.


Using Consumer Priorities with RabbitMQ

December 16, 2013 by Alvaro Videla

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.

When would you want to use Consumer Priorities in your code?


Federated queues in 3.2.0

October 23, 2013 by Simon MacMullen

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.


RabbitMQ 3.1... in images

May 1, 2013 by Simon MacMullen



What's new in RabbitMQ 3.0?

November 20, 2012 by Simon MacMullen

So we’ve talked about how RabbitMQ 3.0 can break things, but that’s not very positive. Let’s have a look at some of the new features! Just some of them - quite a lot changed in 3.0, and we don’t have all day…


Breaking things with RabbitMQ 3.0

November 19, 2012 by

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.


MQTT Adapter

September 12, 2012 by Emile Joubert

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.


Introducing RabbitMQ-Web-Stomp

May 14, 2012 by Marek Majkowski

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.


RabbitMQ 2.7.0 and 2.7.1 are released

December 20, 2011 by Steve Powell

The previous release of RabbitMQ (2.7.0) brought with it a better way of managing plugins, one-stop URI connecting by clients, thread-safe consumers in the Java client, and a number of performance improvements and bug-fixes. The latest release (2.7.1) is essentially a bug-fix release; though it also makes RabbitMQ compatible with Erlang R15B and enhances some of the management interface. The previous release didn’t get a blog post, so I’ve combined both releases in this one.  (These are my own personal remarks and are NOT binding; errors of commission or omission are entirely my own – Steve Powell.)


Performance of Queues: when less is more

October 27, 2011 by Matthew Sackman

Since the new persister arrived in RabbitMQ 2.0.0 (yes, it’s not so new anymore), Rabbit has had a relatively good story to tell about coping with queues that grow and grow and grow and reach sizes that preclude them from being able to be held in RAM. Rabbit starts writing out messages to disk fairly early on, and continues to do so at a gentle rate so that by the time RAM gets really tight, we’ve done most of the hard work already and thus avoid sudden bursts of writes. Provided your message rates aren’t too high or too bursty, this should all happen without any real impact on any connected clients.

Some recent discussion with a client made us return to what we’d thought was a fairly solved problem and has prompted us to make some changes.


High Availability in RabbitMQ: solving part of the puzzle

October 25, 2011 by Matthew Sackman

In RabbitMQ 2.6.0 we introduced Highly Available queues. These necessitated a new extension to AMQP, and a fair amount of documentation, but to date, little has been written on how they work.


rabbitmq-tracing - a UI for the firehose

September 9, 2011 by Simon MacMullen

While the firehose is quite a cool feature, I always thought that it was a shame we didn’t have a simple GUI to go on top and make it accessible to system administrators. So I wrote one. You can download it here.


Federation plugin preview release

June 22, 2011 by Simon MacMullen

Note: this blog post talks about the federation plugin preview that was released for RabbitMQ 2.5.0. If you’re using 2.6.0 or later, federation is part of the main release; get it the same way you would any other plugin.

Another day, another new plugin release 😃 Today it’s federation. If you want to skip this post and just download the plugin, go here. The detailed instructions are here.

The high level goal of federation is to scale out publish / subscribe messaging across WANs and administrative domains.

To do this we introduce the concept of the federation exchange. A federation exchange acts like a normal exchange of a given type (it can emulate the routing logic of any installed exchange type), but also knows how to connect to upstream exchanges (which might in turn themselves be federation exchanges).


Sender-selected distribution

March 23, 2011 by Emile Joubert

RabbitMQ 2.4.0 introduced an extension that allows publishers to specify multiple routing keys in the CC and BCC message headers. The BCC header is removed from the message prior to delivery. Direct and topic exchanges are the only standard exchange types that make use of routing keys, therefore the routing logic of this feature only works with these exchange types.


Introducing Publisher Confirms

February 10, 2011 by Alexandru Scvortov

In many messaging scenarios, you must not lose messages.  Since AMQP gives few guarantees regarding message persistence/handling, the traditional way to do this is with transactions, which can be unacceptably slow.  To remedy this problem, we introduce an extension to AMQP in the form of Lightweight Publisher Confirms.


Who are you? Authentication and authorisation in RabbitMQ 2.3.1

February 7, 2011 by Simon MacMullen

RabbitMQ 2.3.1 introduces a couple of new plugin mechanisms, allowing you much more control over how users authenticate themselves against Rabbit, and how we determine what they are authorised to do. There are three questions of concern here:

  1. How does the client prove its identity over the wire?
  2. Where do users and authentication information (e.g. password hashes) live?
  3. Where does permission information live?

Question 1 is answered in the case of AMQP by SASL - a simple protocol for pluggable authentication mechanisms that is embedded within AMQP (and various other protocols). SASL lets a client and a server negotiate and use an authentication mechanism, without the “outer” protocol having to know any of the details about how authentication works.

SASL offers a number of “mechanisms”. Since the beginning, RabbitMQ has supported the PLAIN mechanism, which basically consists of sending a username and password over the wire in plaintext (of course possibly the whole connection might be protected by SSL). It’s also supported the variant AMQPLAIN mechanism (which is conceptually identical to PLAIN but slightly easier to implement if you have an AMQP codec lying around). RabbitMQ 2.3.1 adds a plugin system allowing you to add or configure more mechanisms, and we’ve written an example plugin which implements the SASL EXTERNAL mechanism.


Ruby AMQP 0.7 released!

January 19, 2011 by Jakub Stastny

I’m happy to announce that the AMQP 0.7 is released, as I promised in the previous blog post. So what are the changes?


AMQP 1.0 prototyping

December 1, 2010 by Michael Bridgen
We have been prototyping support for a new protocol, as is our wont. This one is called “AMQP 1.0 R0”, and it is the new issue from the AMQP working group (of which RabbitMQ, and latterly VMware, are a member). The “R0” indicates that it’s the first revision of a recommendation. The specification is incomplete: there are many TODOs, and to a large extent it is unproven. Those two facts are part of what prompted this prototyping.

Exchange to Exchange bindings

October 19, 2010 by Matthew Sackman

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.


RabbitMQ/0MQ bridge

October 18, 2010 by Martin Sustrik

Recently, Michael Bridgen and I implemented a bridge to connect the RabbitMQ broker with applications using 0MQ for messaging.

Here it is:

So: What kind of benefit the users can get by using both products in parallel?


Management plugin - preview release

September 7, 2010 by Simon MacMullen

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).


Growing Up

August 27, 2010 by Alexis Richardson

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.


Management, monitoring and statistics

August 6, 2010 by Simon MacMullen

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.


RabbitMQ and AMQP 0-9-1

August 4, 2010 by Simon MacMullen

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.


Well, I'll let you go ... basic.reject in RabbitMQ

August 3, 2010 by Michael Bridgen

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.