Quorum Queue Enhancements
RabbitMQ 4.3 brings improvements to Quorum Queues. The most important of those improvements is compaction, related to how Quorum Queues free disk space they no longer need. Users will see less of those situations where queues are short but disk usage is still high, as well as fewer disk alarms and faster recovery after node restart. This is possible thanks to a major change in the underlying Raft (Ra v3) library, which compacts segments that contain partially unused data down to their live entries. Queue snapshot timing was also optimized by tracking how much reclaimable data has accumulated in the queue.
Consumer timeouts and retries were also considerably reworked. Consumer timeout handling was moved from AMQP 0.9.1 channels to quorum queues. This means that streams and classic queues don't time out consumers (streams never did), but quorum queues now enforce the timeout across protocols.
Another improvement for Quorum Queues in RabbitMQ 4.3 is that users can adopt consumer timeouts and delayed retries entirely through policies, so no client library redeployment is required to start using those capabilities.
Consumer timeouts are now also enforced (in quorum queues) for AMQP 1.0 and MQTT, in addition to AMQP 0.9.1 for which it was already enforced in previous versions.
Delayed retries offer a way to delay redelivery of failed deliveries to prevent "poison message" loops and to stabilize traffic spikes.
Lastly,
message priorities
were also completely reworked. Until RabbitMQ 4.2, quorum queues supported only a two-level relative priority system (normal and high). From RabbitMQ 4.3, they support 32 strict priority levels. Note the difference: the old relative priority system delivered messages in a fair-share way. (For every 2 high-priority messages delivered, the queue intentionally delivered 1 normal-priority message.) With the new strict priority ordering, lower-priority messages wait until every single higher-priority message is consumed. Unlike for classic queues, there is no need to define a
x-max-priority
argument on queue declaration. Clients just need to set the priority field in published messages.
Deprecations
The first and biggest deprecation, at least for those using transient non-exclusive queues, is that they are already denied by default in RabbitMQ 4.3 — declarations are rejected unless the deprecated feature is explicitly permitted on every node before upgrading. The RabbitMQ Core Team suggests using durable queues, non-durable but exclusive queues, or durable queues with a TTL, as alternatives.
The next deprecation is
global QoS.
Before RabbitMQ 4.3, global QoS could be used to specify a single prefetch limit shared across all consumers on a channel. This is no longer possible. The reason for the deprecation is that global QoS was only supported by classic queues, and removing the feature made RabbitMQ code clearer and more maintainable. Global QoS could also cause performance issues. In 4.3, the broker denies global QoS by default, by silently converting QoS requests with
global = true
to
global = false.
This means that clients expecting a global prefetch will instead get a per-consumer prefetch.
Finally, the AMQP 1.0 address format v1 is going away. Until RabbitMQ 4.0, the broker only supported one AMQP 1.0 address format. The new one, referred to as v2, reduces ambiguity, is fully URL-encoded, and follows a REST-like scheme. Compared to address v1, it can name any exchange, queue, or routing key safely and predictably. Until RabbitMQ 4.2, both formats were accepted, but in RabbitMQ 4.3, address format v1 is denied by default, so clients need to adapt to this change before targeting 4.3 servers.
Plugins
Regarding RabbitMQ Community Plugins, it is worth mentioning that plugins available for RabbitMQ 4.2 are also supported in RabbitMQ 4.3. As a note, CloudAMQP is continuing the development of the Delayed Message Exchange plugin in our own fork, which already has a release compatible with RabbitMQ 4.3.
The main feature of our Delayed Message Exchange plugin is that it moves away from Mnesia storage and supports no-downtime migration to the new storage, preserving the delayed messages. (Note that our fork of the plugin supports RabbitMQ 4.2.6 and above from the 4.2.x series.)
Get Started with RabbitMQ 4.3 on CloudAMQP
RabbitMQ 4.3 brings major quorum queue enhancements and overall reliability improvements. To get started with a new instance, explore the CloudAMQP plans, and sign up for an account.
To check which version your RabbitMQ cluster is running, go to the "Versions" tab in the CloudAMQP Console. From there, you'll also find the option to upgrade to a newer version of RabbitMQ and Erlang. Read all about upgrades in this blog post.
Have questions about this release or need help upgrading? We're ready to help. Contact CloudAMQP support team!
