Last checked and updated on 01 May 2026What Is New in RabbitMQ 1.4
RabbitMQ 1.4 delivers a solid set of enhancements focused on protocol support, management, and core stability. This release builds a more reliable foundation for production messaging.
| Category | Key Changes |
|---|---|
| New Features | Official AMQP 0-9-1 support, Per-Queue Message TTL, AMQP Transactions. |
| Improvements | Enhanced Mnesia table management, better memory reporting, improved STOMP adapter. |
| Bug Fixes | Multiple fixes for queue durability, exchange bindings, and channel handling. |
| Deprecated | Legacy Shovel plugin configuration (pre-1.4 format). |
How does RabbitMQ 1.4 handle AMQP 0-9-1?
RabbitMQ 1.4 makes AMQP 0-9-1 its default and fully-supported protocol. Previous versions primarily used AMQP 0-8 or 0-9. This matters because 0-9-1 is a more stable, standardized specification that became the baseline for later AMQP work.
In practice, this means clients using libraries for AMQP 0-9-1 get full compatibility without needing protocol adapters. The broker's core queueing, exchange, and binding logic is now aligned with this spec, reducing edge-case inconsistencies.
What management and monitoring upgrades were introduced?
This version brought more granular visibility into the server's state. A significant improvement was in the management of Mnesia tables, which store RabbitMQ's metadata like queue and exchange definitions.
You got better command-line tools for inspecting table health and memory usage. The STOMP adapter also saw stability improvements, making it a more viable option for simple messaging from web clients. These changes were about giving operators the tools to keep the broker running smoothly.
Why is Per-Queue Message TTL a big deal?
Per-Queue Message TTL allows you to set a time-to-live for messages on a specific queue. Before this, controlling message expiration was more cumbersome, often requiring application-level logic.
You declare a queue with an argument like x-message-ttl set to a millisecond value. Any message in that queue exceeding that age is automatically discarded or dead-lettered. This is crucial for cleaning up stale data and managing system resources without writing extra code.
channel.queue_declare(queue='my-queue', arguments={'x-message-ttl': 60000})What core stability fixes should I know about?
The 1.4 release addressed several pesky issues related to durability and channel recovery. Fixes targeted scenarios where durable queue declarations could behave incorrectly after a node restart, or where certain exchange-to-exchange bindings might not persist.
Channel handling, the core of AMQP communication, became more robust, reducing the chance of channel exceptions causing broader connection failures. For any system running near its capacity limits, these fixes directly improved uptime.
FAQ
Is RabbitMQ 1.4 compatible with my existing 1.3 clients?
Yes, for the most part. The switch to AMQP 0-9-1 as the default is backward-compatible with clients using AMQP 0-9. However, you should test clients that use rare, non-standard extensions from earlier protocol versions. The wire protocol is largely unchanged for common operations.
How do I enable transactions in 1.4?
You enable AMQP transactions by using the tx_select method on a channel. After that, publish and ack operations can be batched and committed with tx_commit or rolled back with tx_rollback. In practice, most high-throughput systems later moved to publisher confirms, as transactions are synchronous and impact performance.
What happens to messages when Per-Queue TTL expires?
By default, the messages are simply deleted. RabbitMQ 1.4 does not have a built-in dead-lettering feature for TTL-expired messages. If you need to capture them, you must implement that logic in your consumer application.
Were there any breaking changes in the management API?
The core management HTTP API was still evolving at this point. While no major breaking changes were announced in 1.4, the deprecated Shovel plugin configuration format is a breaking change if you were using that specific plugin. Always check plugin documentation when upgrading.
Should I upgrade from 1.3 to 1.4 in production?
If you are running 1.3 in production, upgrading to 1.4 is recommended for the protocol stability and bug fixes. Plan a maintenance window and test your specific workload, especially around queue durability and channel recovery, which had targeted fixes. The improvements in operational visibility alone are worth it.