RabbitMQ 3.10 has recently been released and has some major new features which focus on optimizations, performance, and stability.

Release notes page includes information about the specific changes in this version as well as various installation assets. See our upgrade guide for more information about upgrading to 3.10.0.

Let’s have a tour!

RabbitMQ RPM packages for CentOS 7 will be discontinued from May 2022 because that CentOS release series provides outdated versions of OpenSSL and Linux kernel.

CentOS 7 users are recommended to migrate to a new cluster which uses a more recent distribution via one of the options:

• In-place Upgrades
• definition transfer
• Blue-Green Deployment upgrade.

Quorum queues in RabbitMQ 3.10 provide a safer form of dead lettering that uses at-least-once guarantees for the message transfer between queues. This blog post explains everything you need to know to start using at-least-once dead lettering.

This post also introduces two other RabbitMQ 3.10 features: message Time-To-Live (TTL) for quorum queues and Prometheus metrics for dead lettered messages.

We intend to release RabbitMQ 3.10.0 on 11 April 2022. While we have been testing it internally for some time, with production-like workloads, we need your help to check that it is as stable and reliable as we believe it is.

Many organizations have policies around RabbitMQ usage wich they would like to enforce. This blog post explains via example how the Open Policy Agent Gatekeeper project can be used in combination with the RabbitMQ Messaging Topology Operator to manage RabbitMQ resources on Kubernetes and enforce policies on those resources by extending the Kubernetes API.

RabbitMQ is not affected by the Log4j vulnerability, read below for more details.

RabbitMQ streams allow applications to convey detailled information thanks to the powerful message format they use. Streams are a feature of their own, but they also fully integrate with the existing resources and protocols that RabbitMQ supports. This blog post covers the interoperability of streams in RabbitMQ and explores the scenarios it unlocks.

RabbitMQ Streams provides server-side offset tracking for consumers. This features allows a consuming application to restart consuming where it left off in a previous run. This post covers the semantics of offset tracking and how it is implemented in the stream Java client.

In RabbitMQ 4.0, we intend to remove some RabbitMQ features to:

• Increase the resiliency of the core broker
• Decrease the number of suboptimal configurations available
• Remove technical surface area (maintaining old code) from the team
• Reduce the support burden

We continually innovate to meet and exceed our users’ expectations. Removal of older functionality that no longer meets these expectations, or serves our users, means we can focus on our mission to provide a stable, performant, and flexible messaging system.

RabbitMQ Streams Overview introduced streams, a new feature in RabbitMQ 3.9 and RabbitMQ Streams First Application provided an overview of the programming model with the stream Java client. This post covers how to deduplicate published messages in RabbitMQ Streams.

As deduplication is a critical and intricate concept, the post will walk you through this mechanism step by step, from a naive and somewhat broken publishing application to an optimized and reliable implementation.