RabbitMQ 4.3.0-rc.0 is a preview of a new feature release.
Breaking Changes and Compatibility Notes
Mnesia and Parition Handling Strategies are Removed
Since only 4.2.x clusters can upgrade to 4.3.0 in place, this
won't be a breaking change for nearly all instalations but
All partition handling-related keys in rabbitmq.conf will be
accepted by 4.3.0 nodes but won't have any effect:
cluster_partition_handlingcluster_partition_handling.pause_if_all_down.recovercluster_partition_handling.pause_if_all_down.nodes.$name
Still, Team RabbitMQ recommends removing the above keys from rabbitmq.conf before or shortly
after upgrading.
Classic Queues v1 Storage (CQv1) is Removed
This release removes the original classic queue storage implementation these days
known as CQv1. A 2nd generation implementation called CQv2 has been adopted
as the default starting with 4.2.0.
This means that attempts to declare a queue using the following optional queue arguments will fail:
x-queue-modeset to any valuex-queue-versionset to1
Existing classic queues upgraded to CQv2 during an earlier upgrade to 4.2.x will continue
operating as usual.
Consumer Timeouts are No Longer Evaluated for Classic Queues and Streams
This release moves consumer timeout handling responsibility into the queues
themselves. Also, all protocols (except the stream protocol) now evaluate
consumer timeout for queue types that support them. Classic queues and streams
never evaluate consumer timeouts as their use cases cause less demand for it.
Release Highlights
Khepri is Now The Only Metadata Store
As of this release, Khepri is the only metadata store supported
by RabbitMQ: Mnesia was removed completely.
In practical operational terms, this means that
- For a cluster to be available, a majority of nodes must be online at all times
- Failure and partition recovery in a RabbitMQ cluster is now significantly
simpler and uniform: all components that have replicated state (Khepri, quorum queues, streams)
recover per Raft recovery semantics
Quorum Queues Enhancements
This release upgrades the Ra dependency to 3.x and introduces
a new (8th) version of the quorum queue state machine with several new features and optimisations:
- Strict priority queues with per-priority message counts, correct
redelivery ordering, and priority-aware message expiration - Delayed retry for quorum queues: configurable increasing backoff when
messages are returned - Consumer timeout for quorum queues: configurable timeout for
unacknowledged messages, with protocol-specific handling for AMQP 1.0 and
MQTT - Recovery snapshots and snapshot throttling to reduce recovery time
and improve snapshotting decisions - Memory optimisations including compact message references, optimised
tuple storage for delayed keys, and removal ofrabbit_fifo_indexusage
Upgrading to 4.3.0
Documentation guides on upgrades
See the Upgrading guide for documentation on upgrades and GitHub releases
for release notes of individual releases.
This release series supports upgrades from 4.2.x. Upgrades from earlier series are not supported:
users must upgrade to the latest available 4.2.x patch release before upgrading to 4.3.0.
New Required Feature Flags
All feature flags introduced in 4.2.0 and earlier are required, including the following:
rabbitmq_4.2.0rabbitmq_4.1.0rabbitmq_4.0.0khepri_dbquorum_queue_non_votersmessage_containers_deaths_v2
Enable all required feature flags before upgrading to 4.3.0.
If your RabbitMQ cluster had plugin rabbitmq_amqp1_0 enabled in RabbitMQ 3.13.x (and your cluster still serves AMQP 1.0 client connections in 4.x), your cluster should do at least one rolling update after enabling feature flag rabbitmq_4.0.0 but before upgrading to 4.3.0.
Deprecated Features
In 4.3.0 the deprecation phase of the following features advanced from permitted_by_default to denied_by_default:
amqp_address_v1amqp_filter_set_bugglobal_qosqueue_master_locatortransient_nonexcl_queues
And the deprecated feature ram_node_type has been removed.
Mixed version cluster compatibility
RabbitMQ 4.3.0 nodes can run alongside 4.2.x in the same cluster.
Mixed version clusters are a mechanism that allows rolling upgrades and are not meant to be run for extended
periods of time (no more than a few hours).
Recommended Post-upgrade Procedures
This version does not require any additional post-upgrade procedures
compared to other versions.
Changes Worth Mentioning
Core Server
Enhancements
-
When a message is rejected by a queue, RabbitMQ now provides the queue name and rejection reason to AMQP 1.0 publishers
in theRejectedoutcome. This is particularly useful when multiple queues are bound to an exchange, as it allows
publishers to identify which specific queue out of several target queues rejected the message and why
(e.g., maximum queue length reached or queue unavailable). Previously, publishers had no way to determine which queue
rejected their message or the reason for rejection.The queue name and reason are included in the
infofield of theRejectedoutcome'serrorfield:queue: <queue name>reason: maxlen | unavailable
GitHub issue: #15075
-
Quorum queues now support strict priority queues with per-priority message counts,
correct redelivery ordering across priorities, and priority-aware message expiration scans.GitHub issue: #13885
-
Quorum queues now support delayed retry with configurable backoff based on delivery count. When messages
are returned (via reject, nack, or modify), they can be held in a delayed state before becoming
available again. The delay is based on delivery count:min(min_delay * delivery_count, max_delay).Configuration is available via queue arguments (
x-delayed-retry-type,x-delayed-retry-min,
x-delayed-retry-max) or policy keys (delayed-retry-type,delayed-retry-min,
delayed-retry-max). The retry type can be set todisabled,all,failed, orreturned.GitHub issue: #13885
-
Quorum queues now support a configurable consumer timeout. When a consumer holds unacknowledged
messages beyond the timeout, the messages are returned to the queue. For AMQP 1.0 clients,
timed-out deliveries are released viaDISPOSITION(state=released)instead of detaching the link,
allowing the consumer to recover without re-attaching. MQTT consumers are also supported.The timeout can be set via the
x-consumer-timeoutconsumer argument, queue argument,consumer-timeout
policy key, or the globalconsumer_timeoutsetting inrabbitmq.conf.GitHub issue: #13885
-
A new
consumer_disconnected_timeoutsetting controls how long quorum queues wait before returning
messages when a consumer's node becomes unreachable due to a network partition. The default is 60 seconds.
Configurable viaconsumer_disconnected_timeoutinrabbitmq.conf, theconsumer-disconnected-timeout
policy key, or thex-consumer-disconnected-timeoutqueue argument.GitHub issue: #13885
-
Quorum queue recovery snapshots reduce recovery time after a member restart by avoiding
the need to replay all enqueue commands from the log.GitHub issue: #13885
-
Quorum queue snapshot throttling now uses WAL fill ratio and reclaimable byte tracking
to make smarter snapshotting decisions, yielding roughly one snapshot per queue per WAL cycle
instead of excessive snapshots in shallow, fast-flowing queues.GitHub issue: #13885
-
Quorum queue memory optimisations: message references now use a compact packed integer
representation ("compact" means up to 59-bit) when possible, halving per-message
memory overhead in many scenarios. Therabbit_fifo_indexmodule is no longer used by the
main state machine.GitHub issue: #13885
-
Quorum queues now allow unlimited explicit message returns. The delivery limit is based on
delivery-countrather thanacquired-count, so messages can be explicitly returned to the
queue without counting towards the delivery limit.GitHub issue: #13885
-
When quorum queue members (replicas) are deleted from a node, either manually
viarabbitmq-queues shrinkor as part ofrabbitmqctl forget_cluster_node,
the members are stopped in parallel.GitHub issue: #15081
-
Purging a quorum queue now also removes at-least-once dead-lettered messages that were pending delivery.
GitHub issue: #13885
Bug Fixes
-
If a quorum queue with a large backlog terminated abnormally, node memory
footprint could spike.GitHub issue: #15837
-
rabbitmqctl forget_cluster_nodenow removes all quorum queue and stream members (replicas)
before proceeding to leave the metadata store cluster.This order minimizes the risk of some replicas being left behind on the leaving node.
GitHub issue: #15729
-
Quorum queue at-most-once dead lettering for the overflow behaviour
drop-headnow happens in the correct order.GitHub issue: #14926
-
Feature flag state in the registry and on disk were not consistent for a period of time during node boot.
GitHub issue: #14943
-
Classic queues now implement AMQP 1.0 delivery-count and first-acquirer headers properly.
GitHub issue: #15020
Stream Plugin
Bug Fixes
-
stream.read_aheadis a new setting that controls how much data is prefetched from disk
for stream reads (consumption).GitHub issue: #14948/
-
Stream deletion is now more resilient and can handle certain mid-deletion failure scenarios.
GitHub issue: #14852
Grafana Dashboards
Enhancements
- The dashboards were updated for the most recent RabbitMQ release series.
Management Plugin
Enhancements
-
GET /api/queues/{vhost}requests no longer perform unnecessary virtual host permission checks
and log less (atdebuglevel) as a result.GitHub issue: #14923
-
Quorum queue delayed retry configuration and status, per-priority message counts, and consumer
timeout state are now displayed in the management UI.GitHub issue: #13885
-
GET /users/{user}/queueshas been added.GitHub issue: #15074
MQTT Plugin
Enhancements
-
For MQTT 5.0 publishers, when a message is rejected because the target queue's maximum length is exceeded,
RabbitMQ now returns aQuota exceededreason code in the PUBACK packet. This provides publishers with
actionable information about why their message was rejected.GitHub issue: #15075
Federation Plugin
Enhancements
-
Federation links and their connections are now stopped in parallel.
This significantly improves shutdown time for nodes with many (into thousands) federation links.
GitHub issue: #15271
-
Federation links no longer restart during plugin or node shutdown.
For nodes with hundreds or thousands of federation links, link recovery could
significantly delay node shutdown.GitHub issue: #15258
Shovel Plugin
Enhancements
- An optional
src-consumer-nameproperty can be specified to define the consumer tag
(amqp091andlocalsrc-protocol) or link identifier (amqp10protocol)
Bug Fixes
-
Improved target node resource alarm handling for AMQP 1.0 and local shovels.
GitHub issue: #14886
-
Local shovels could run into an exception that would cause a shovel restart.
GitHub issue: #14872
-
AMQP 1.0 shovels ignored the
saslURI parameter.GitHub issue: #14867
OAuth 2 Plugin
Bug Fixes
-
A usability improvement allows the plugin to automatically load the trusted system x.509 (TLS) certificates.
GitHub issue: #14927
LDAP Plugin
Enhancements
-
LDAP queries, including multi-line ones, can now be specified in
rabbitmq.conf.GitHub issue: #14868
Bug Fixes
-
A usability improvement allows the plugin to automatically load the trusted system certificates
when the user only enables TLS for the LDAP client but does not configure any other settings.GitHub issue: #14937
HTTP Auth Backend Plugin
Enhancements
-
The HTTP Auth Backend can now optionally provide a custom authorization denial reason to AMQP clients.
To opt in, return
deny <Reason>(instead of onlydeny) in the HTTP response body of your HTTP auth backend and set the following in yourrabbitmq.conffile:
auth_http.authorization_failure_disclosure = trueSee the README for more information.
GitHub issue: #14641
Tracing Plugin
Bug Fixes
-
Trace file downloads now set the charset to UTF-8 when serving trace files.
GitHub issue: #13952
Dependency Changes
rawas upgraded from2.17.2to3.1.2osiriswas upgraded to1.3.0cuttlefishwas upgraded to3.6.0gen_batch_serverwas upgraded to0.9.2
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-4.3.0.tar.xz
instead of the source tarball produced by GitHub.