Last checked and updated on 01 May 2026What Is New in RabbitMQ 3.1
RabbitMQ 3.1.0 is a significant release that introduces a new plug-in architecture and several core improvements. This version focuses on making the broker more extensible and easier to manage.
| Category | Key Changes |
|---|---|
| New Features | New Plugin System, Per-Message Time-to-Live (TTL) |
| Improvements | Management Plugin UI, MQTT Protocol Support |
| Bug Fixes | Various stability and connection handling fixes |
| Deprecated | Old plugin format (e.g., rabbitmq-plugin commands) |
What is the new plugin system in RabbitMQ 3.1?
The core change in 3.1 is a completely revamped plugin system. This new architecture makes plugins first-class citizens within the broker, allowing for deeper integration and more powerful extensions.
In practice, this means plugins can now hook into more internal subsystems. You enable them the same way, but their potential for adding new protocols, authentication mechanisms, and other behaviors is greatly expanded.
How does per-message TTL work?
RabbitMQ 3.1 introduced the ability to set a Time-to-Live (TTL) on individual messages. Previously, TTL could only be set on a queue, which applied to all messages within it.
You set it by including the expiration property in the message's AMQP headers. The value is a string representing the milliseconds a message can live in the queue before being automatically discarded. This is useful for ensuring stale data doesn't clog your queues.
// Example: Publishing a message with a 60-second TTL
Map<String, Object> headers = new HashMap<>();
headers.put("expiration", "60000");
AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()
.headers(headers)
.build();
channel.basicPublish("my-exchange", "routing.key", props, messageBodyBytes);What improvements were made to the Management UI?
The management plugin received a substantial UI refresh in this version. The interface became more intuitive, providing better visibility into connections, channels, and queue metrics.
It also added better support for managing the new plugin system directly from the web console. This matters because it reduces the operational overhead of managing and monitoring a RabbitMQ cluster.
Was MQTT support improved?
Yes, MQTT protocol support saw significant enhancements. The built-in MQTT adapter became more stable and feature-complete, making RabbitMQ a stronger contender for IoT and mobile messaging scenarios.
The improvements included better handling of QoS levels and persistent sessions. This allowed for more reliable message delivery guarantees for clients using the MQTT protocol.
FAQ
Is the new plugin system backwards compatible?
Mostly. Plugins written for the old system should still work, but to take full advantage of the new capabilities, they need to be updated to the new API.
Does per-message TTL override queue TTL?
Yes. If both a per-message TTL and a queue TTL are set, the shorter of the two values is enforced. This gives you fine-grained control over message expiration.
Should I upgrade to 3.1 in production?
If you rely on a stable, battle-tested release, you might wait for a subsequent bugfix release like 3.1.1. However, for new deployments or to use the new features, 3.1.0 is a solid foundation.
What was the main motivation for the plugin system rewrite?
The old system was limiting. The rewrite future-proofed RabbitMQ, making it easier to develop complex extensions without modifying the core broker, which is crucial for ecosystem growth.
Are there any known performance regressions in 3.1.0?
For most workloads, performance is on par with 3.0.x. However, as with any major release, you should benchmark your specific use case. Some edge cases with the new plugin infrastructure were ironed out in later patches.