RabbitMQ 3.2: What's New, Release History & EOL Status

What Is New in RabbitMQ 3.2

RabbitMQ 3.2 introduced a significant set of features focused on improving performance and providing finer-grained control over the broker's behavior. The key changes are summarized below.

How did message expiration improve in 3.2?

RabbitMQ 3.2 introduced two powerful ways to control message expiration, moving beyond the previous limitation of only setting a TTL on a per-queue basis.

You can now set a message-ttl on a queue, which applies to all messages in that queue, or you can set a ttl property on individual messages when publishing. The per-message TTL takes precedence. This matters because it allows for much more flexible messaging patterns, like having transient command messages alongside more durable event messages in the same queue.

In practice, if a message sits in a queue longer than its TTL, it is automatically dead-lettered or discarded. This feature is essential for building systems that need to handle time-sensitive data without creating clutter.

What are queue length limits and why use them?

Version 3.2 added the ability to set a maximum number of messages (x-max-length) or a maximum total message size in bytes (x-max-length-bytes) for a queue.

When the limit is reached, RabbitMQ drops messages from the head of the queue (the oldest messages) to make room for new ones. This is a form of a bounded queue and is critical for preventing a fast producer from overwhelming a slow consumer and causing the broker to run out of disk space.

We use this all the time for monitoring or logging queues where losing old data is preferable to bringing the entire system to a halt. It’s a simple but effective back-pressure mechanism.

How did federation evolve in this release?

This release built upon the existing Federation plugin by introducing federation support for shovel links. Shovels are a simpler, point-to-point method for moving messages between brokers or clusters.

By treating shovels as federated resources, you can manage and monitor them through the same federation management UI and API. This creates a more unified experience for building distributed messaging topologies, whether you need the flexibility of federation or the simplicity of a shovel.

It meant you could now set up a reliable, replicated shovel and see its status right alongside your other federated resources, simplifying operational oversight.

Were there any under-the-hood performance gains?

Yes, significant work was done on the Erlang VM and the core server to reduce memory footprint and improve overall stability under heavy load.

The internal flow control mechanisms were enhanced to be more responsive, preventing publishers from overwhelming queues and consumers more effectively. This resulted in smoother performance and better overall throughput, especially in scenarios with mixed workloads and variable network conditions.

You might not have seen a specific feature toggle for this, but your clusters likely ran more predictably after upgrading.

What changed for developers using the HTTP API?

The management HTTP API was expanded with new endpoints, providing deeper insights and more control over the newly introduced features.

You could now programmatically inspect and manage per-queue TTL settings, length limits, and get more detailed statistics. This made it easier to build custom tooling and automation around queue provisioning and monitoring without needing to rely solely on the web UI.