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.

RabbitMQ Streams Overview introduced streams, a new feature in RabbitMQ 3.9. This post covers how client applications should connect to RabbitMQ nodes to get the most benefit from streams when the stream protocol is in use.

Streams are optimized for high throughput scenarios, that’s why technical details like data locality are critical to get the best out of your RabbitMQ cluster. Client libraries can handle most of the details, but a basic understanding of how things work under the hood is essential when a setup involves extra layers like containers and load balancers. Keep reading if you want to learn more about streams and avoid some headaches when deploying your first stream applications!

RabbitMQ Streams Overview introduced streams, a new feature in RabbitMQ 3.9. This post continues by showing how to use streams with the Java client. We will write our first application that publishes messages to a stream, and then consumes them.

RabbitMQ 3.9 introduces a new type of data structure: streams. Streams unlock a set of use cases that could have been tedious to implement with “traditional” queues. Let’s discover in this post how streams expand the capabilities of RabbitMQ.

We intend to release RabbitMQ 3.9.0 on 26 July 2021. While we have been testing it internally for months, with production-like workloads, we need your help to check that it is as stable and reliable as we believe it is.

TL;DR

• Erlang 24 will ship in May and it offers significant performance gains to RabbitMQ users
• Supporting Erlang 24 and 22 at the same time is not feasible, so in early May 2021, Erlang 22 support will be dropped
• If you run on Erlang 22, upgrade to 23.2 today: it should be a drop-in replacement
• Users of the RabbitMQ Kubernetes Operator, the Docker community image and modern releases of VMware Tanzu RabbitMQ for VMs are not affected as those projects all use Erlang 23 today

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.