Menu

Archive for the ‘New Features’ Category

RabbitMQ Gets an HA Upgrade

Monday, April 20th, 2020

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:

(more…)

RabbitMQ 3.8 Release Overview

Monday, November 11th, 2019

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.

(more…)

Simplifying rolling upgrades between minor versions with feature flags

Tuesday, April 23rd, 2019

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.

Minor Version Upgrades Today: RabbitMQ 3.6.x to 3.7.x

It you had to upgrade a cluster from RabbitMQ 3.6.x to 3.7.x, you probably had to use one of the following solutions:

  • Deploy a new cluster alongside the existing one (this strategy is known as the blue-green deployment), then migrate data & clients to the new cluster
  • Stop all nodes in the existing cluster, upgrade the last node that was stopped first, then continue upgrading all other nodes, one-by-one

Blue-green deployment strategy is low risk but also fairly complex to automate. On the other hand, a cluster-wide shutdown affects availability. Feature flags are meant to provide a 3rd option by making rolling cluster upgrades possible and reasonably easy to automate.

(more…)

RabbitMQ Java Client Metrics with Micrometer and Datadog

Tuesday, April 10th, 2018

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.

(more…)

New Configuration Format in RabbitMQ 3.7

Thursday, February 22nd, 2018

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

(more…)

Peer Discovery Subsystem in RabbitMQ 3.7

Monday, February 12th, 2018

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

(more…)

What’s New in RabbitMQ 3.7

Monday, February 5th, 2018

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.

(more…)

New Reactive Client for RabbitMQ HTTP API

Wednesday, October 18th, 2017

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.

(more…)

RabbitMQ Java Client 5.0 is Released

Friday, September 29th, 2017

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.

(more…)

Brand new rabbitmqctl in 3.7.0

Thursday, December 15th, 2016

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:

  • We wanted to use a more user-friendly command line parser and produce more useful help and error messages.
  • CLI tools should be extensible from plugins: plugins such as management, federation, shovel, trust store all have functions that are meant to be invoked by CLI tools but the only way of doing it was rabbitmqctl eval, which is error prone and can be dangerous.
  • We wanted to give Elixir a try on a real project and make it easier for developers new to Erlang to extend the CLI functionality.
  • Our CLI tools historically didn't have good test coverage; the new ones should (and do).
  • CLI tools should be able to produce machine-friendly formats, be it JSON, CSV or something else; there was no internal infrastructure for doing that in the original implementation.
  • CLI tools should be a separate repository just like all plugins, client libraries, and so on.
Nine months later the experiment was declared a success and integrated into RabbitMQ distribution.

Please give v3.7.0 Milestone 8 a try and take a look at how easy it is to extend the CLI.

There's also a longer document that covers new features and implementation decisions.