Releases: rabbitmq/rabbitmq-server
RabbitMQ 3.13.0-rc.2
RabbitMQ 3.13.0-rc.2
RabbitMQ 3.13.0-rc.2
is a candidate of a new feature release.
Highlights
This release includes several new features and optimizations.
The user-facing areas that have seen the biggest improvements in this release are
- Khepri now can be used as an alternative schema data store
in RabbitMQ, replacing Mnesia - Support for consumer-side stream filtering
- MQTTv5 support
- A new common message container format used internally, based on the AMQP 1.0 message container format
- Improved classic non-mirrored queue performance with message sizes larger than
4 KiB (or a different customized CQ index embedding threshold) - Classic queues use version 2 of the storage implementation (CQv2).
This should significantly improve performance of non-mirrored classic queues
See Compatibility Notes below to learn about breaking or potentially breaking changes in this release.
Release Artifacts
RabbitMQ preview releases are distributed via GitHub.
Community Docker image is another installation option
for previews. It is updated with a delay (usually a few days).
Erlang/OTP Compatibility Notes
This release requires Erlang 26.0 or later.
Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision latest patch versions of Erlang 26.x.
Upgrading to 3.13
Documentation guides on upgrades
See the Upgrading guide for documentation on upgrades and RabbitMQ change log
for release notes of other releases.
Note that since 3.12.0 requires all feature flags to be enabled before upgrading,
there is no upgrade path from from 3.11.24 (or a later patch release) straight to 3.13.0.
Required Feature Flags
This release does not graduate any feature flags.
However, all users are highly encouraged to enable all feature flags before upgrading to this release from
3.12.x.
Mixed version cluster compatibility
RabbitMQ 3.13.0 nodes can run alongside 3.12.x
nodes. 3.13.x
-specific features can only be made available when all nodes in the cluster
upgrade to 3.13.0 or a later patch release in the new series.
While operating in mixed version mode, some aspects of the system may not behave as expected. The list of known behavior changes is covered below.
Once all nodes are upgraded to 3.13.0, these irregularities will go away.
Mixed version clusters are a mechanism that allows rolling upgrade and are not meant to be run for extended
periods of time (no more than a few hours).
Compatibility Notes
This release includes a few potentially breaking changes&
Minimum Supported Erlang Version
Starting with this release, RabbitMQ requires Erlang 26.0 or later versions. Nodes will fail to start
on older Erlang releases.
Client Library Compatibility
Client libraries that were compatible with RabbitMQ 3.12.x
will be compatible with 3.13.0
.
RabbitMQ Stream Protocol clients must be upgraded to use the stream filtering feature
introduced in this release.
Consistency Model and Schema Modification Visibility Guarantees of Khepri and Mnesia
Khepri has an important difference from Mnesia when it comes to schema modifications such as queue
or stream declarations, or binding declarations. These changes won't be noticeable with many workloads
but can affect some, in particular, certain integration tests.
Consider two scenarios, A and B.
Scenario A
There is only one client. The client performs the following steps:
- It declares a queue Q
- It binds Q to an exchange X
- It publishes a message M to the exchange X
- It expects the message to be routed to queue Q
- It consumes the message
In this scenario, there should be no observable difference in behavior. Client's expectations
will be met.
Scenario B
There are two clients, One and Two, connected to nodes R1 and R3, and using the same virtual host.
Node R2 has no client connections.
Client One performs the following steps:
- It declares a queue Q
- It binds Q to an exchange X
- It gets a queue declaration confirmation back
- It notifies client 2 or client 2 implicitly finds out that it has finished the steps above (for example, in an integration test)
- Client Two publishes a message M to X
- Clients One and Two expect the message to be routed to Q
In this scenario, on step three Mnesia would return when all cluster nodes have committed an update.
Khepri, however, will return when a majority of nodes, including the node handling Client One's operations,
have returned.
This may include nodes R1 and R2 but not node R3, meaning that message M published by Client Two connected to node R3
in the above example is not guaranteed not be routed.
Once all schema changes propagate to node R3, Client Two's subsequent
publishes on node R3 will be guaranteed to be routed.
This trade-off of a Raft-based system that assume that a write accepted by a majority of nodes
can be considered a succeess.
To satisfy Client Two's expectations in scenario B Khepri could beform consistent (involving a majority of replicas)
queries of bindings when routing messages but that would have a significant impact on throughput
of certain protocols (such as MQTT) and exchange/destination types (anything that resembles a topic exchange in AMQP 0-9-1).
Management Plugin and HTTP API
GET /api/queues` HTTP API endpoint has dropped several rarely used metrics, resulting in 25% in traffic saving.
MQTT Plugin
mqtt.subscription_ttl
(in milliseconds) configuration setting was replaced with mqtt.max_session_expiry_interval_seconds
(in seconds).
A 3.13 RabbitMQ node will fail to boot if the old configuration setting is set.
For example, if you set mqtt.subscription_ttl = 3600000
(1 hour) prior to 3.13, replace that setting with mqtt.max_session_expiry_interval_seconds = 3600
(1 hour) in 3.13.
openSUSE Leap Package is not Provided
An openSUSE Leap package will not be provided with this release of RabbitMQ.
This release requires Erlang 26 and there is an Erlang 26 package available from Erlang Factory
but the package depends on glibc
2.34, and all currently available openSUSE Leap releases
(up to 15.5) ship with 2.31 at most.
Team RabbitMQ would like to continue building a openSUSE Leap package when a Leap 15.5-compatible Erlang 26
package becomes publicly available.
Getting Help
Any questions about this release, upgrades or RabbitMQ in general are welcome in GitHub Discussions or
on our community Discord.
Changes Worth Mentioning
Release notes are kept under rabbitmq-server/release-notes.
Core Server
Enhancements
-
Khepri now can be used as an alternative schema data store
in RabbitMQ, by enabling a feature flag:rabbitmqctl enable_feature_flag khepri_db
In practical terms this means that it will be possible to swap Mnesia for a Raft-based data store
that will predictably recover from network partitions and node failures, the same way quorum queues
and streams already do. At the same time, this means
that RabbitMQ clusters now must have a majority of nodes online at all times, or all client operations will be refused.Like quorum queues and streams, Khepri uses RabbitMQ's Raft implementation under the hood. With Khepri enabled, all key modern features
of RabbitMQ will use the same fundamental approach to recovery from failures, relying on a library that passes a Jepsen test suite.Team RabbitMQ intends to make Khepri the default schema database starting with RabbitMQ 4.0.
GitHub issue: #7206
-
Messages are now internally stored using a new common heavily AMQP 1.0-influenced container format. This is a major step towards a protocol-agnostic core:
a common format that encapsulates a sum of data types used by the protocols RabbitMQ supports, plus annotations for routng, dead-lettering state,
and other purposes.AMQP 1.0, AMQP 0-9-1, MQTT and STOMP have or will adopt this internal representation in upcoming releases. RabbitMQ Stream protocol already uses the AMQP 1.0 message container
structure internally.This common internal format will allow for more correct and potentially efficient multi-protocol support in RabbitMQ,
and that most cross-protocol translation rough edges can be smoothened.GitHub issue: #5077
-
Target quorum queue replica state is now continuously reconciled.
When the number of online replicas of a quorum q...
RabbitMQ 3.12.8
RabbitMQ 3.12.8
is a maintenance release in the 3.12.x
release series.
Please refer to the upgrade section from the 3.12.0 release notes
if upgrading from a version prior to 3.12.0.
This release requires Erlang 25 and supports Erlang versions up to 26.1.x
.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.
Minimum Supported Erlang Version
As of 3.12.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases.
Users upgrading from 3.11.x (or older releases) on Erlang 25 to 3.12.x on Erlang 26
(both RabbitMQ and Erlang are upgraded at the same time) must consult
the v3.12.0 release notes first.
Changes Worth Mentioning
Release notes can be found on GitHub at rabbitmq-server/release-notes.
Core Server
Bug Fixes
-
Avoids a potential exception in the
autoheal
partition handler.Contributed by @Ayanda-D.
GitHub issue: #9818
Enhancements
-
raft.segment_max_entries
is now validated to prevent the value from overflowing its 16-bit segment file field.
Maximum supported value is now65535
.GitHub issue: #9733
Shovel Plugin
Enhancements
-
Significantly faster Shovel startup in environments where there are many of them (one thousand or more).
GitHub issue: #9796
AMQP 1.0 Erlang Client
Enhancements
-
User-provided credentials are now obfuscated using an one-off key pair generated on node boot.
This keeps sensitive client state information from being logged by the runtime exception logger.GitHub issue: #9777
Dependency Upgrades
None in this release.
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.12.8.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 3.11.25
RabbitMQ 3.11.25
is a maintenance release in the 3.11.x
release series.
This release series goes out of community support on Dec 31, 2023.
Please refer to the upgrade section from v3.11.0 release notes
if upgrading from a version prior to 3.11.0.
This release requires Erlang 25 and supports Erlang versions up to 25.3.x
.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.
Minimum Supported Erlang Version
As of 3.11.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases.
Erlang 25 as our new baseline means much improved performance on ARM64 architectures, profiling with flame graphs
across all architectures, and the most recent TLS 1.3 implementation available to all RabbitMQ 3.11 users.
Changes Worth Mentioning
Release notes can be found on GitHub at rabbitmq-server/release-notes.
Core Server
Bug Fixes
-
Avoids a potential exception in the
autoheal
partition handler.Contributed by @Ayanda-D.
GitHub issue: #9819
Enhancements
-
raft.segment_max_entries
is now validated to prevent the value from overflowing its 16-bit segment file field.
Maximum supported value is now ``65535.GitHub issue: #9748
Shovel Plugin
Enhancements
-
Significantly faster Shovel startup in environments where there are many of them (one thousand or more).
GitHub issue: #9800
AMQP 1.0 Erlang Client
Enhancements
-
User-provided credentials are now obfuscated using an one-off key pair generated on node boot.
This keeps sensitive client state information from being logged by the runtime exception logger.GitHub issue: #9778
Dependency Upgrades
None in this release.
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.11.25.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 3.13.0-rc.1
RabbitMQ 3.13.0-rc.1
RabbitMQ 3.13.0-rc.1
is a candidate of a new feature release.
Highlights
This release includes several new features and optimizations.
The user-facing areas that have seen the biggest improvements in this release are
- Khepri now can be used as an alternative schema data store
in RabbitMQ, replacing Mnesia - Support for consumer-side stream filtering
- MQTTv5 support
- A new common message container format used internally, based on the AMQP 1.0 message container format
- Improved classic non-mirrored queue performance with message sizes larger than
4 KiB (or a different customized CQ index embedding threshold) - Classic queues use version 2 of the storage implementation (CQv2).
This should significantly improve performance of non-mirrored classic queues
See Compatibility Notes below to learn about breaking or potentially breaking changes in this release.
Release Artifacts
RabbitMQ preview releases are distributed via GitHub.
Community Docker image is another installation option
for previews. It is updated with a delay (usually a few days).
Erlang/OTP Compatibility Notes
This release requires Erlang 26.0 or later.
Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision latest patch versions of Erlang 26.x.
Upgrading to 3.13
Documentation guides on upgrades
See the Upgrading guide for documentation on upgrades and RabbitMQ change log
for release notes of other releases.
Note that since 3.12.0 requires all feature flags to be enabled before upgrading,
there is no upgrade path from from 3.11.24 (or a later patch release) straight to 3.13.0.
Required Feature Flags
This release does not graduate any feature flags.
However, all users are highly encouraged to enable all feature flags before upgrading to this release from
3.12.x.
Mixed version cluster compatibility
RabbitMQ 3.13.0 nodes can run alongside 3.12.x
nodes. 3.13.x
-specific features can only be made available when all nodes in the cluster
upgrade to 3.13.0 or a later patch release in the new series.
While operating in mixed version mode, some aspects of the system may not behave as expected. The list of known behavior changes is covered below.
Once all nodes are upgraded to 3.13.0, these irregularities will go away.
Mixed version clusters are a mechanism that allows rolling upgrade and are not meant to be run for extended
periods of time (no more than a few hours).
Compatibility Notes
TBD
Minimum Supported Erlang Version
Starting with this release, RabbitMQ requires Erlang 26.0 or later versions. Nodes will fail to start
on older Erlang releases.
Client Library Compatibility
Client libraries that were compatible with RabbitMQ 3.12.x
will be compatible with 3.13.0
.
RabbitMQ Stream Protocol clients must be upgraded to use the stream filtering feature
introduced in this release.
Getting Help
Any questions about this release, upgrades or RabbitMQ in general are welcome in GitHub Discussions or
on our community Discord.
Changes Worth Mentioning
Release notes are kept under rabbitmq-server/release-notes.
Core Server
Enhancements
-
Khepri now can be used as an alternative schema data store
in RabbitMQ, by enabling a feature flag:rabbitmqctl enable_feature_flag khepri_db
In practical terms this means that it will be possible to swap Mnesia for a Raft-based data store
that will predictably recover from network partitions and node failures, the same way quorum queues
and streams already do. At the same time, this means
that RabbitMQ clusters now must have a majority of nodes online at all times, or all client operations will be refused.Like quorum queues and streams, Khepri uses RabbitMQ's Raft implementation under the hood. With Khepri enabled, all key modern features
of RabbitMQ will use the same fundamental approach to recovery from failures, relying on a library that passes a Jepsen test suite.Team RabbitMQ intends to make Khepri the default schema database starting with RabbitMQ 4.0.
GitHub issue: #7206
-
Messages are now internally stored using a new common heavily AMQP 1.0-influenced container format. This is a major step towards a protocol-agnostic core:
a common format that encapsulates a sum of data types used by the protocols RabbitMQ supports, plus annotations for routng, dead-lettering state,
and other purposes.AMQP 1.0, AMQP 0-9-1, MQTT and STOMP have or will adopt this internal representation in upcoming releases. RabbitMQ Stream protocol already uses the AMQP 1.0 message container
structure internally.This common internal format will allow for more correct and potentially efficient multi-protocol support in RabbitMQ,
and that most cross-protocol translation rough edges can be smoothened.GitHub issue: #5077
-
Target quorum queue replica state is now continuously reconciled.
When the number of online replicas of a quorum queue goes below (or above) its target,
new replicas will be automatically placed if enough cluster nodes are available.
This is a more automatic version of how quorum queue replicas have originally been grown.For automatic shrinking of queue replicas, the user must opt in.
Contributed by @SimonUnge (AWS).
GitHub issue: #8218
-
Reduced memory footprint, improved memory use predictability and throughput of classic queues (version 2, or CQv2).
This particularly benefits classic queues with longer backlogs.Classic queue v2 (CQv2) storage implementation is now the default. It is possible to switch
the default back to CQv1 usingrabbitmq.conf
:# uses CQv1 by default classic_queue.default_version = 1
Individual queues can be declared by passing
x-queue-version
argument and/or through aqueue-version
policy.GitHub issue: #8308
-
Non-mirrored classic queues: optimizations of storage for larger (greater than 4 kiB) messages.
-
A subsystem for marking features as deprecated.
GitHub issue: #7390
-
Plugins now can register custom queue types. This means that a plugin now can provide
a custom queue type.Contributed by @luos (Erlang Solutions).
Bug Fixes
This release includes all bug fixes shipped in the 3.12.x
series.
-
Feature flag discovery on a newly added node could discover an incomplete inventory of feature flags.
GitHub issue: #8477
-
Feature flag discovery operations will now be retried multiple times in case of network failures.
GitHub issue: #8491
-
The state of node maintenance status across the cluster is now replicated. It previously was accessible
to all nodes but not replicated.GitHub issue: #9005
Management Plugin
Enhancements
-
New API endpoint,
GET /api/stream/{vhost}/{name}/tracking
, can be used to track
publisher and consumer offsets in a stream.GitHub issue: #9642
-
Several rarely used queue metrics were removed to reduce inter-node data transfers
and CPU burn during API response generation. The effects will be particularly pronounced
for theGET /api/queues
endpoint used without filtering or pagination, which can produce
enormously large responses.A couple of relevant queue metrics or state fields were lifted to the top level.
This is a potentially breaking change.
Note that Prometheus is the recommended option for monitoring,
not the management plugin's HTTP API.
Stream Plu...
RabbitMQ 3.12.7
RabbitMQ 3.12.7
is a maintenance release in the 3.12.x
release series.
Please refer to the upgrade section from the 3.12.0 release notes
if upgrading from a version prior to 3.12.0.
This release requires Erlang 25 and supports Erlang versions up to 26.1.x
.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.
Minimum Supported Erlang Version
As of 3.12.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases.
Users upgrading from 3.11.x (or older releases) on Erlang 25 to 3.12.x on Erlang 26
(both RabbitMQ and Erlang are upgraded at the same time) must consult
the v3.12.0 release notes first.
Changes Worth Mentioning
Release notes can be found on GitHub at rabbitmq-server/release-notes.
Core Server
Bug Fixes
-
Stream replication connections configured to use exclusively TLSv1.3 failed.
GitHub issue:#9678
-
On startup, stream replicas will handle one more potential case of segment file corruption
after an unclean shutdown.Contributed by @gomoripeti (CloudAMQP).
GitHub issue: #9678
-
default_policies.*.queue_pattern
definition inrabbitmq.conf
was incorrectly parsed.Contributed by @SimonUnge (AWS).
GitHub issue: #9545
-
Avoid log noise when inter-node connections frequently fail and recover.
Contributed by @Ayanda-D.
GitHub issue: #9667
Enhancements
-
Optimized stream index scans. Longer scans could result in some replicas stopping
with a timeout.GitHub issue:#9678
-
Classic queue storage version is now a supported key for operator policies.
Contributed by @SignalWhisperer (AWS).
GitHub issue: #9548
-
Queue length limit overflow behavior now can be configured via operator policies.
Contributed by @SimonUnge (AWS).
GitHub issue: #9636
CLI Tools
Bug Fixes
-
rabbitmq-streams list_stream_consumer_groups
incorrectly validated the set of columns it accepts.GitHub issue: #9671
Enhancements
-
Several
list_stream_*
commands (available via bothrabbitmq-diagnostics
andrabbitmq-streams
) commands now can
display replica node in addition to other fields.GitHub issue: #9582
-
rabbitmqctl add_user
now can accept a pre-generated salted password instead
of a plain text password, both as a positional argument and via standard input:# This is just an example, DO NOT use this value in production! # The 2nd argument is a Base64-encoded pre-hashed and salted value of "guest4" rabbitmqctl -- add_user "guest4" "BMT6cj/MsI+4UOBtsPPQWpQfk7ViRLj4VqpMTxu54FU3qa1G" --pre-hashed-password # try authenticating with a pair of credentials rabbitmqctl authenticate_user "guest4" "guest4"
GitHub issue: #9669
Management Plugin
Bug Fixes
-
Message consumption with the "Nack message, requeue: true" option did not actually requeue deliveries.
GitHub issue: #9715
Enhancements
-
HTTP API request body size is now limited to 10 MiB by default.
Two endpoints, one that accepts messages for publishing (note: publishing over the HTTP API is greatly discouraged)
and another for definition import,
will now reject larger transfers with a400 Bad Request
response.GitHub issue: #9708
-
DELETE /api/queues/{vhost}/{name}
now can delete exclusive queues.GitHub issue: #8758
-
Key supported by operator policies are now grouped by queue type in the UI.
GitHub issue: #9544
MQTT Plugin
Enhancements
-
Improved data safety for confirms in environments where the plugin uses classic queues.
GitHub issue: #9530
Web MQTT Plugin
Bug Fixes
-
Avoid an exception when a not fully established MQTT-over-WebSockets connection terminated.
Contributed by @gomoripeti (CloudAMQP).
GitHub issue: #9654
JMS Topic Exchange Plugin
Bug Fixes
-
Recovery of bindings of durable queues bound to a transient JMS topic exchange failed.
GitHub issue: #9533
Sharding Plugin
Bug Fixes
-
Recovery of bindings of durable queues bound to a transient
x-modulo-hash
exchange failed.GitHub issue: #9533
Recent History Exchange Plugin
Bug Fixes
-
Recovery of bindings of durable queues bound to a transient recent history exchange failed.
GitHub issue: #9533
Dependency Upgrades
osiris
has been upgraded to1.6.9
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.12.7.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 3.11.24
RabbitMQ 3.11.24
is a maintenance release in the 3.11.x
release series.
This release series goes out of community support on Dec 31, 2023.
Please refer to the upgrade section from v3.11.0 release notes
if upgrading from a version prior to 3.11.0.
This release requires Erlang 25 and supports Erlang versions up to 25.3.x
.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.
Minimum Supported Erlang Version
As of 3.11.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases.
Erlang 25 as our new baseline means much improved performance on ARM64 architectures, profiling with flame graphs
across all architectures, and the most recent TLS 1.3 implementation available to all RabbitMQ 3.11 users.
Changes Worth Mentioning
Release notes can be found on GitHub at rabbitmq-server/release-notes.
Core Server
Bug Fixes
-
Stream replication connections configured to use exclusively TLSv1.3 failed.
GitHub issue:#9678
-
On startup, stream replicas will handle one more potential case of segment file corruption
after an unclean shutdown.Contributed by @gomoripeti (CloudAMQP).
GitHub issue: #9678
-
default_policies.*.queue_pattern
definition inrabbitmq.conf
was incorrectly parsed.Contributed by @SimonUnge (AWS).
GitHub issue: #9546
Enhancements
-
Optimized stream index scans. Longer scans could result in some replicas stopping
with a timeout.GitHub issue:#9678
-
Classic queue storage version is now a supported key for operator policies.
Contributed by @SignalWhisperer (AWS).
GitHub issue: #9549
-
Nodes now log boot time at info level instead of debug. This piece of information
can be useful during root cause analysis.Contributed by @johanrhodin (CloudAMQP).
GitHub issue: #9466
Management Plugin
Enhancements
-
HTTP API request body size is now limited to 10 MiB by default.
Two endpoints, one that accepts messages for publishing (note: publishing over the HTTP API is greatly discouraged)
and another for definition import,
will now reject larger transfers with a400 Bad Request
response.GitHub issue: #9708
-
DELETE /api/queues/{vhost}/{name}
now can delete exclusive queues.GitHub issue: #8758
Dependency Upgrades
osiris
has been upgraded to1.6.9
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.11.24.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 3.12.6
RabbitMQ 3.12.6
is a maintenance release in the 3.12.x
release series.
Please refer to the upgrade section from the 3.12.0 release notes
if upgrading from a version prior to 3.12.0.
This release requires Erlang 25 and supports Erlang versions up to 26.1.x
.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.
Minimum Supported Erlang Version
As of 3.12.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases.
Users upgrading from 3.11.x (or older releases) on Erlang 25 to 3.12.x on Erlang 26
(both RabbitMQ and Erlang are upgraded at the same time) must consult
the v3.12.0 release notes first.
Changes Worth Mentioning
Release notes can be found on GitHub at rabbitmq-server/release-notes.
Core Server
Bug Fixes
-
3.12.5
unintentionally shipped with aseshat
version older than0.6.1
. This can potentially
result in an incompatibility with the stream subsystem.GitHub issue: #9499
Enhancements
-
Improved forward compatibility of classic queues with 3.13.
GitHub issue: #9508
Dependency Upgrades
seshat
was upgraded to0.6.1
Dependency Upgrades
None in this release.
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.12.6.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 3.12.5
RabbitMQ 3.12.5
is a maintenance release in the 3.12.x
release series.
All users are encouraged to skip this version in favor of 3.12.6
.
Please refer to the upgrade section from the 3.12.0 release notes
if upgrading from a version prior to 3.12.0.
This release requires Erlang 25 and supports Erlang versions up to 26.1.x
.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.
Minimum Supported Erlang Version
As of 3.12.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases.
Users upgrading from 3.11.x (or older releases) on Erlang 25 to 3.12.x on Erlang 26
(both RabbitMQ and Erlang are upgraded at the same time) must consult
the v3.12.0 release notes first.
Changes Worth Mentioning
Release notes can be found on GitHub at rabbitmq-server/release-notes.
Core Server
Bug Fixes
-
Quorum queue leader changes are now correctly observed in certain network failure scenarios.
-
High consumer churn with reused consumer tag on quorum queues could result in some messages not being delivered
after a period of time.This did not affect environments where consumer churn does not exist or where it does but consumer tags vary.
GitHub issue: #9158
-
Three environment variables,
LOG_BASE
,MNESIA_BASE
,CONFIG_FILE
, were not picked up when set in
rabbitmq-env-conf.bat
on Windows.GitHub issue: #9307
-
Avoids a potential exception when autoheal partition handling process was initiated.
GitHub issue: #9222
-
Avoids a potential exception in the credit flow subsystem.
Contributed by @Ayanda-D.
GitHub issue: #9433
-
Classic queues v2 (CQv2) that had priorities enabled were reporting their storage version
incorrectly.Contributed by @gomoripeti (CloudAMQP).
GitHub issue: #9370
Enhancements
-
Channels that had many thousands of consumers (usually due to a consumer leak in the application)
now consume a lot less CPU resources when the channel is closed.As part of this optimization, individual
consumer.deleted
internal events are no
longer emitted when a channel is closed, only achannel.closed
event is. This also
help reduce audit event log size, since thoseconsumer.deleted
events provided
no useful information in this context.Contributed by @SimonUnge (AWS).
GitHub issue: #9356
-
Initial forward compatibility with later Erlang 26.x and 27.0 releases.
GitHub issue: #9485
-
Nodes now log boot time at info level instead of debug. This piece of information
can be useful during root cause analysis.Contributed by @johanrhodin (CloudAMQP).
GitHub issue: #9466
-
Channel interceptors (defined by plugins) now can return one more type of errors.
Contributed by @Ayanda-D.
GitHub issue: #9459
CLI Tools
Bug Fixes
-
rabbitmqctl delete_queue
now handles more queue replica failure scenarios
(that were previously handled by client operations and the HTTP API but not CLI tools).Contributed by @Ayanda-D.
GitHub issue: #9324
-
rabbitmq-streams delete_replica
now handles scenarios where the replica is hosted
on a node that is not accessiable (reachable).GitHub issue: #9282
MQTT Plugin
Bug Fixes
-
If a socket write fails, close the connection quickly to avoid producing a lot of
log noise.GitHub issue: #9281
AMQP 1.0 Plugin
Bug Fixes
-
Listing AMQP 1.0 connections in a system that had both AMQP 1.0 and AMQP 0-9-1 clients connected
resulted in exceptions logged and partial results returned to CLI tools.GitHub issue: #9371
Prometheus Plugin
Enhancements
-
The plugin now exposes a new gauge,
rabbitmq_unreachable_cluster_peers_count
, that indicates how many cluster
peers cannot be reached by this node.Contributed by @gomoripeti (CloudAMQP).
Dependency Upgrades
osiris
was upgraded to1.6.7
Dependency Upgrades
None in this release.
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.12.5.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 3.11.23
RabbitMQ 3.11.23
is a maintenance release in the 3.11.x
release series.
This release series goes out of community support on Dec 31, 2023.
Please refer to the upgrade section from v3.11.0 release notes
if upgrading from a version prior to 3.11.0.
This release requires Erlang 25 and supports Erlang versions up to 25.3.x
.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.
Minimum Supported Erlang Version
As of 3.11.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases.
Erlang 25 as our new baseline means much improved performance on ARM64 architectures, profiling with flame graphs
across all architectures, and the most recent TLS 1.3 implementation available to all RabbitMQ 3.11 users.
Changes Worth Mentioning
Release notes can be found on GitHub at rabbitmq-server/release-notes.
Core Server
Bug Fixes
-
High consumer churn with reused consumer tag on quorum queues could result in some messages not being delivered
after a period of time.This did not affect environments where consumer churn does not exist or where it does but consumer tags vary.
GitHub issue: #9164
-
Three environment variables,
LOG_BASE
,MNESIA_BASE
,CONFIG_FILE
, were not picked up when set in
rabbitmq-env-conf.bat
on Windows.GitHub issue: #9308
-
Avoids a potential exception when autoheal partition handling process was initiated.
GitHub issue: #9223
Dependency Upgrades
osiris
was upgraded to1.6.4
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.11.23.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 3.13.0-beta.6
RabbitMQ 3.13.0-beta.6
RabbitMQ 3.13.0-beta.6
is a preview of a new feature release.
Highlights
This release includes several new features, optimizations, and graduates (makes mandatory) a number of feature flags.
The user-facing areas that have seen the biggest improvements in this release are
- Support for consumer-side stream filtering
- MQTTv5 support
- A new common message container format used internally, based on the AMQP 1.0 message container format
- Improved classic non-mirrored queue performance with message sizes larger than
4 KiB (or a different customized CQ index embedding threshold) - Classic queues use version 2 of the storage implementation (CQv2).
This should significantly improve performance of non-mirrored classic queues
This release also features many internal API improvements in preparation to 4.0
with Khepri.
See Compatibility Notes below to learn about breaking or potentially breaking changes in this release.
Release Artifacts
RabbitMQ preview releases are distributed via GitHub.
Community Docker image is another installation option
for previews. It is updated with a delay (usually a few days).
Erlang/OTP Compatibility Notes
This release requires Erlang 26.0 or later.
Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision latest patch versions of Erlang 26.x.
Upgrading to 3.13
Documentation guides on upgrades
See the Upgrading guide for documentation on upgrades and RabbitMQ change log
for release notes of other releases.
Required Feature Flags
TBD
Mixed version cluster compatibility
RabbitMQ 3.13.0 nodes can run alongside 3.12.x
nodes. 3.12.x
-specific features can only be made available when all nodes in the cluster
upgrade to 3.13.0 or any other patch release in the new series.
While operating in mixed version mode, some aspects of the system may not behave as expected. The list of known behavior changes is covered below.
Once all nodes are upgraded to 3.13.0, these irregularities will go away.
Mixed version clusters are a mechanism that allows rolling upgrade and are not meant to be run for extended
periods of time (no more than a few hours).
Compatibility Notes
TBD
Minimum Supported Erlang Version
Starting with this release, RabbitMQ requires Erlang 26.0 or later versions. Nodes will fail to start
on older Erlang releases.
Client Library Compatibility
Client libraries that were compatible with RabbitMQ 3.12.x
will be compatible with 3.13.0
.
Getting Help
Any questions about this release, upgrades or RabbitMQ in general are welcome on the RabbitMQ mailing list.
Changes Worth Mentioning
Release notes are kept under rabbitmq-server/release-notes.
Core Server
Enhancements
-
Messages are now internally stored using a new common heavily AMQP 1.0-influenced container format. This is a major step towards a protocol-agnostic core:
a common format that encapsulates a sum of data types used by the protocols RabbitMQ supports, plus annotations for routng, dead-lettering state,
and other purposes.AMQP 1.0, AMQP 0-9-1, MQTT and STOMP have or will adopt this internal representation in upcoming releases. RabbitMQ Stream protocol already uses the AMQP 1.0 message container
structure internally.This common internal format will allow for more correct and potentially efficient multi-protocol support in RabbitMQ,
and that most cross-protocol translation rough edges can be smoothened.GitHub issue: #5077
-
Target quorum queue replica state is now continuously reconciled.
When the number of online replicas of a quorum queue goes below (or above) its target,
new replicas will be automatically placed if enough cluster nodes are available.
This is a more automatic version of how quorum queue replicas have originally been grown.For automatic shrinking of queue replicas, the user must opt in.
Contributed by @SimonUnge (AWS).
GitHub issue: #8218
-
Reduced memory footprint, improved memory use predictability and throughput of classic queues (version 2, or CQv2).
This particularly benefits classic queues with longer backlogs.Classic queue v2 (CQv2) storage implementation is now the default. It is possible to switch
the default back to CQv1 usingrabbitmq.conf
:# uses CQv1 by default classic_queue.default_version = 1
Individual queues can be declared by passing
x-queue-version
argument and/or through aqueue-version
policy.GitHub issue: #8308
-
Non-mirrored classic queues: optimizations of storage for larger (greater than 4 kiB) messages.
-
A subsystem for marking features as deprecated.
GitHub issue: #7390
-
Plugins now can register custom queue types. This means that a plugin now can provide
a custom queue type.Contributed by @luos (Erlang Solutions).
Bug Fixes
This release includes all bug fixes shipped in the 3.12.x
series.
-
Feature flag discovery on a newly added node could discover an incomplete inventory of feature flags.
GitHub issue: #8477
-
Feature flag discovery operations will now be retried multiple times in case of network failures.
GitHub issue: #8491
-
The state of node maintenance status across the cluster is now replicated. It previously was accessible
to all nodes but not replicated.GitHub issue: #9005
Stream Plugin
Enhancements
-
Support for (consumer) stream filtering.
This allows consumers that are only interested in a subset of data in a stream to receive
less data. Note that false positives are possible, so this feature should be accompanied by
client library or application-level filtering.GitHub issue: #8207
MQTT Plugin
Enhancements
-
Support for MQTTv5 (with limitations).
-
Negative message acknowledgements are now propagated to MQTTv5 clients.
GitHub issue: #9034
-
Potential incompatibility:
mqtt.subscription_ttl
configuration setting is now deprecated in favor of
mqtt.max_session_expiry_interval_seconds
that targets MQTTv5.GitHub issue: #8846
AMQP 1.0 Plugin
Bug Fixes
-
During AMQP 1.0 to AMQP 0-9-1 conversion, the Correlation ID message property is now stored as
x-correlation-id
(instead ofx-correlation
) for values longer than 255 bytes.This is a potentially breaking change.
GitHub issue: #8680
Dependency Changes
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.13.0.tar.xz
instead of the source tarball produced by GitHub.