Last checked and updated on 01 May 2026What Is New in RabbitMQ 3.6
RabbitMQ 3.6 introduced several key enhancements focused on plugin stability, management capabilities, and protocol support. This release built upon the core Erlang-based messaging foundation with incremental but important improvements for operators and developers.
| Category | Key Changes |
|---|---|
| New Features & Plugins | Enhanced MQTT plugin, Shovel management via CLI, improved Federation status reporting. |
| Management & Monitoring | Richer HTTP API for queue details, better UI for plugin management, and connection/channel tracking. |
| Protocol Support | Stricter AMQP 0-9-1 compliance and MQTT 3.1.1 improvements. |
| Core Server & Performance | Internal queue index optimizations, memory use reductions for connections, and bug fixes for message persistence. |
| Deprecations & Removals | Old, deprecated management API endpoints were phased out in favor of newer, more consistent ones. |
How Were Management and Monitoring Improved?
The management plugin received significant attention in 3.6. The HTTP API exposed more granular data, particularly around queue state and message rates, which is crucial for debugging backpressure.
In practice, you could get better visibility into channel-level flow control and consumer counts directly from the API. The web UI also improved its handling of large numbers of connections and queues, making it more responsive for busy brokers.
Specific API Enhancements
- Extended queue details: included consumer utilization and backpressure indicators.
- Improved connection and channel listing: added filtering capabilities by user or vhost.
- Plugin management: enabled starting, stopping, and enabling plugins via the HTTP API, not just the CLI.
What Changed for MQTT and Other Plugins?
The MQTT plugin saw stability and spec compliance upgrades. It better handled MQTT 3.1.1 clean sessions and will messages, which mattered for IoT-style use cases where connections are flaky.
The Shovel and Federation plugins became more manageable. For Shovel, you could now dynamically update shovel parameters via the rabbitmqctl command without restarting the plugin. Federation link status reporting became more detailed, showing why a link was idle or failing.
# Example: Managing a Shovel dynamically in 3.6
rabbitmqctl set_parameter shovel my-shovel \
'{"src-uri": "amqp://src", "src-queue": "jobs", \
"dest-uri": "amqp://dest", "dest-queue": "processed-jobs"}'Were There Under-the-Hood Performance Tweaks?
Yes, several core optimizations landed. The message store's queue index saw improvements that reduced disk I/O under certain persistent queue workloads. This was a niche but critical win for users pushing high volumes of durable messages.
Memory footprint for idle connections was reduced. RabbitMQ has always been efficient with resources, but 3.6 trimmed overhead further. This matters when you're hosting thousands of lightly connected producers or consumers.
Internal routing and topic matching algorithms were refined. While not a user-facing feature, it meant lower CPU usage for complex topic exchange bindings in large setups.
What Should Developers Watch Out For When Upgrading?
Upgrading from 3.5.x to 3.6 was generally smooth, but there were behavioral changes. The deprecated management API endpoints were removed, so any monitoring scripts using those old URLs needed updating to the new ones.
AMQP 0-9-1 compliance became stricter. Some edge-case client behaviors that were previously tolerated might start throwing connection errors. Testing your client applications against the new version before a production rollout was essential.
Recommended Upgrade Steps
- Review and update any scripts using the deprecated management API endpoints.
- Test MQTT client reconnection logic if using the MQTT plugin.
- Verify Federation and Shovel configurations post-upgrade, as the status API changed.
FAQ
Is RabbitMQ 3.6 suitable for use with MQTT in production?
Yes, the MQTT plugin improvements in 3.6 made it more robust for production use, especially around session handling. However, for new deployments, consider a later 3.7.x or 3.8.x release which includes even more MQTT features and stability.
Can I manage Shovel configurations without restarting in 3.6?
Yes, this was a key addition. You could use rabbitmqctl set_parameter to create or modify Shovel and Federation links dynamically, which was a major operational improvement over previous versions.
What happened to the old management API endpoints?
They were removed. If your monitoring or tooling relied on paths like /api/queues/[vhost]/[queue]?msgrates=true (old style), you needed to update them to use the newer, more consistent API endpoints introduced in earlier 3.x releases.
Did the internal message format change in 3.6?
No, the persistent message store format (Mnesia) did not change between 3.5 and 3.6. This meant a rolling upgrade from 3.5.x to 3.6.x without message loss was straightforward.
Are there any known issues with lazy queues in 3.6?
Lazy queues, introduced earlier, saw further stability fixes in 3.6. However, some edge cases around memory usage and large backlog purging persisted. It's generally advised to test lazy queue behavior under your specific load pattern.