Releases: rabbitmq/rabbitmq-server
RabbitMQ 4.0.0-beta.5
RabbitMQ 4.0.0-beta.5
is a preview of a new major release.
Starting June 1st, 2024, community support for this series will only be provided to regularly contributing users and those who hold a valid commercial support license.
Highlights
Some key improvements in this release are listed below.
- Khepri, an alternative schema data store developed to replace Mnesia, is no longer considered an experimental feature
- AMQP 1.0 is now a core protocol that is always enabled. Its plugin is now a no-op that only exists to simplify upgrades.
- The AMQP 1.0 implementation is now significantly more efficient: its peak throughput is more than double than that of 3.13.x
on some workloads - Efficient sub-linear quorum queue recovery on node startup using checkpoints
- Quorum queues now support priorities (but not exactly the same way as classic queues)
- AMQP 1.0 clients now can manage topologies similarly to how AMQP 0-9-1 clients do it
- The AMQP 1.0 convention (address format) used for interacting with with AMQP 0-9-1 entities is now easier to reason about
- Mirroring (replication) of classic queues was removed after several years of deprecation. For replicated messaging data types,
use quorum queues and/or streams. Non-replicated classic queues remain and their development continues - Classic queue storage efficiency improvements, in particular recovery time and storage of multi-MiB messages
- Nodes with multiple enabled plugins and little on disk data to recover now start up to 20-30% faster
- New exchange type: Local Random Exchange
See Compatibility Notes below to learn about breaking or potentially breaking changes in this release.
Breaking Changes and Compatibility Notes
Classic Queues is Now a Non-Replicated Queue Type
After three years of deprecated, classic queue mirroring was completely removed in this version.
Quorum queues and streams are two mature
replicated data types offered by RabbitMQ 4.x. Classic queues continue being supported without any breaking changes
for client libraries and applications but they are now a non-replicated queue type.
After an upgrade to 4.0, all classic queue mirroring-related parts of policies will have no effect.
Classic queues will continue to work like before but with only one replica.
Clients will be able to connect to any node to publish to and consume from any non-replicated classic queues.
Therefore applications will be able to use the same classic queues as before.
See Mirrored Classic Queues Migration to Quorum Queues for guidance
on how to migrate to quorum queues for the parts of the system that really need to use replication.
Quorum Queues Now Have a Default Redelivery Limit
Quorum queues now have a default redelivery limit set to 20
.
CQv1 Storage Implementation was Removed
CQv1, the original classic queue storage layer, was removed
except for the part that's necessary for upgrades to CQv2 (the 2nd generation).
In case rabbitmq.conf
explicitly sets classic_queue.default_version
to 1
like so
# this configuration value is no longer supported,
# remove this line or set the version to 2
classic_queue.default_version = 1
nodes will now fail to start. Removing the line will make the node start and perform
the migration from CQv1 to CQv2.
Several Disk I/O-Related Metrics were Removed
Several I/O-related metrics are dropped, they should be monitored at the infrastructure and kernel layers
Default Maximum Message Size Reduced to 16 MiB
Default maximum message size is reduced to 16 MiB (from 128 MiB).
The limit can be increased via a rabbitmq.conf
setting:
# 32 MiB
max_message_size = 33554432
However, it is recommended that such large multi-MiB messages are put into a blob store, and their
IDs are passed around in messages instead of the entire payload.
AMQP 1.0
RabbitMQ 3.13 rabbitmq.conf
setting rabbitmq_amqp1_0.default_vhost
is unsupported in RabbitMQ 4.0.
Instead default_vhost
will be used to determine the default vhost an AMQP 1.0 client connects to(i.e. when the AMQP 1.0 client does not define the vhost in the hostname
field of the open
frame).
MQTT
RabbitMQ 3.13 rabbitmq.conf settings mqtt.default_user
, mqtt.default_password
,
and amqp1_0.default_user
are unsupported in RabbitMQ 4.0.
Instead, set the new RabbitMQ 4.0 settings anonymous_login_user
and anonymous_login_pass
(both values default to guest
).
For production scenarios, disallow anonymous logins.
Shovels
RabbitMQ Shovels will be able connect to a RabbitMQ 4.0 node via AMQP 1.0 only when the Shovel runs on a RabbitMQ node >= 3.13.7
.
Erlang/OTP Compatibility Notes
This release requires Erlang 26.2.
Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision latest patch versions of Erlang 26.x.
Release Artifacts
RabbitMQ releases are distributed via GitHub.
Debian and RPM packages are available via Cloudsmith mirrors.
Community Docker image, Chocolatey package, and the Homebrew formula
are other installation options. They are updated with a delay.
Upgrading to 4.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 only supports upgrades from 3.13.x
.
This release requires all feature flags in the 3.x series (specifically 3.13.x
) to be enabled before upgrading,
there is no upgrade path from 3.12.14 (or a later patch release) straight to 4.0.0
.
Required Feature Flags
This release graduates all feature flags introduced up to 3.13.0
.
All users must enable all stable [feature flags] before upgrading to 4.0 from
the latest available 3.13.x patch release.
Mixed version cluster compatibility
RabbitMQ 4.0.0 nodes can run alongside 3.13.x
nodes. 4.0.x
-specific features can only be made available when all nodes in the cluster
upgrade to 4.0.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 will be covered in future updates.
Once all nodes are upgraded to 4.0.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).
Recommended Post-upgrade Procedures
Set a low priority dead lettering policy for all quorum queues to dead letter to a stream or similar
so that messages that reach the new default delivery limit of 20 aren't lost completely
when no dead lettering policy is in place.
TBD
Changes Worth Mentioning
This section is incomplete and will be expanded as 4.0 approaches its release candidate stage.
Core Server
Enhancements
-
Efficient sub-linear quorum queue recovery on node startup using checkpoints.
GitHub issue: #10637
-
Classic queue storage v2 (CQv2) optimizations. For example, CQv2 recovery time on node boot
is now twice as fast for some data sets.GitHub issue: #11112
-
Node startup time improvements. For some environments, nodes with very small on disk data sets
now start about 25% quicker.GitHub issue: #10989
-
Quorum queues now support priorities. However,
there are difference with how priorities work in classic queues.GitHub issue: #10637
-
Per-message metadata stored in the quorum queue Raft log now uses less disk space.
GitHub issue: #8261
-
Single Active Consumer (SAC) implementation of quorum queues now respects consumer priorities....
RabbitMQ 4.0.0-beta.4
RabbitMQ 4.0.0-beta.4
is a preview of a new major release.
Starting June 1st, 2024, community support for this series will only be provided to regularly contributing users and those who hold a valid commercial support license.
Highlights
Some key improvements in this release are listed below.
- Khepri, an alternative schema data store developed to replace Mnesia, has matured
- AMQP 1.0 is now a core protocol that is always enabled. Its plugin is now a no-op that only exists to simplify upgrades.
- The AMQP 1.0 implementation is now significantly more efficient: its peak throughput is more than double than that of 3.13.x
on some workloads - Efficient sub-linear quorum queue recovery on node startup using checkpoints
- Quorum queues now support priorities (but not exactly the same way as classic queues)
- AMQP 1.0 clients now can manage topologies similarly to how AMQP 0-9-1 clients do it
- The AMQP 1.0 convention (address format) used for interacting with with AMQP 0-9-1 entities is now easier to reason about
- Mirroring (replication) of classic queues was removed after several years of deprecation. For replicated messaging data types,
use quorum queues and/or streams. Non-replicated classic queues remain and their development continues - Classic queue storage efficiency improvements, in particular recovery time and storage of multi-MiB messages
- Nodes with multiple enabled plugins and little on disk data to recover now start up to 20-30% faster
- CQv1, the original classic queue storage layer, was removed except for the part that's necessary for upgrades
- Several I/O-related metrics are dropped, they should be monitored at the infrastructure and kernel layers
See Compatibility Notes below to learn about breaking or potentially breaking changes in this release.
Release Artifacts
RabbitMQ releases are distributed via GitHub.
Debian and RPM packages are available via Cloudsmith mirrors.
Community Docker image, Chocolatey package, and the Homebrew formula
are other installation options. They are updated with a delay.
Erlang/OTP Compatibility Notes
This release requires Erlang 26.2.
Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision latest patch versions of Erlang 26.x.
Upgrading to 4.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 only supports upgrades from 3.13.x
.
This release requires all feature flags in the 3.x series (specifically 3.13.x
) to be enabled before upgrading,
there is no upgrade path from 3.12.14 (or a later patch release) straight to 4.0.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.13.x.
Mixed version cluster compatibility
RabbitMQ 4.0.0 nodes can run alongside 3.13.x
nodes. 4.0.x
-specific features can only be made available when all nodes in the cluster
upgrade to 4.0.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 will be covered in future updates.
Once all nodes are upgraded to 4.0.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).
Recommended Post-upgrade Procedures
TBD
Changes Worth Mentioning
TBD
Dependency Changes
- Ra was upgraded to
2.13.5
- Khepri was upgraded to
0.14.0
- Cuttlefish was upgraded to
3.4.0
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-4.0.0-beta.4.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 4.0.0-beta.3
RabbitMQ 4.0.0-beta.3
is a preview of a new major release.
Starting June 1st, 2024, community support for this series will only be provided to regularly contributing users and those who hold a valid commercial support license.
Highlights
Some key improvements in this release are listed below.
- Khepri, an alternative schema data store developed to replace Mnesia,
has matured - AMQP 1.0 is now a core protocol that is always enabled. Its plugin is now a no-op that only exists to simplify upgrades.
- The AMQP 1.0 implementation is now significantly more efficient: its peak throughput is more than double than that of 3.13.x
on some workloads - AMQP 1.0 clients now can manage topologies similarly to how AMQP 0-9-1 clients do it
- The AMQP 1.0 convention (address format) used for interacting with with AMQP 0-9-1 entities is now easier to reason about
- Mirroring (replication) of classic queues was removed after several years of deprecation. For replicated messaging data types,
use quorum queues and/or streams. Non-replicated classic queues remain and their development continues - Classic queue storage efficiency improvements, in particular recovery time and storage of multi-MiB messages
- Nodes with multiple enabled plugins and little on disk data to recover now start up to 20-30% faster
- CQv1, the original classic queue storage layer, was removed except for the part that's necessary for upgrades
- Several I/O-related metrics are dropped, they should be monitored at the infrastructure and kernel layers
See Compatibility Notes below to learn about breaking or potentially breaking changes in this release.
Release Artifacts
RabbitMQ releases are distributed via GitHub.
Debian and RPM packages are available via Cloudsmith mirrors.
Community Docker image, Chocolatey package, and the Homebrew formula
are other installation options. They are updated with a delay.
Erlang/OTP Compatibility Notes
This release requires Erlang 26.2.
Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision latest patch versions of Erlang 26.x.
Upgrading to 4.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 only supports upgrades from 3.13.x
.
This release requires all feature flags in the 3.x series (specifically 3.13.x
) to be enabled before upgrading,
there is no upgrade path from 3.12.14 (or a later patch release) straight to 4.0.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.13.x.
Mixed version cluster compatibility
RabbitMQ 4.0.0 nodes can run alongside 3.13.x
nodes. 4.0.x
-specific features can only be made available when all nodes in the cluster
upgrade to 4.0.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 will be covered in future updates.
Once all nodes are upgraded to 4.0.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).
Recommended Post-upgrade Procedures
TBD
Changes Worth Mentioning
TBD
Dependency Changes
- Ra was upgraded to
2.13.5
- Khepri was upgraded to
0.14.0
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-4.0.0-beta.3.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 3.13.6
RabbitMQ 3.13.6
is a maintenance release in the 3.13.x
release series.
This upgrade is highly recommended to all users currently on earlier 3.13.x
series and
in particular between 3.13.3
and 3.13.5
, inclusive.
Starting June 1st, 2024, community support for this series will only be provided to regularly contributing users and those
who hold a valid commercial support license.
Please refer to the upgrade section from the 3.13.0 release notes
if upgrading from a version prior to 3.13.0.
This release requires Erlang 26 and supports Erlang versions up to 26.2.x
.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.
Minimum Supported Erlang Version
As of 3.13.0, RabbitMQ requires Erlang 26. Nodes will fail to start on older Erlang releases.
Users upgrading from 3.12.x (or older releases) on Erlang 25 to 3.13.x on Erlang 26
(both RabbitMQ and Erlang are upgraded at the same time) must consult
the v3.12.0 release notes and v3.13.0 release notes first.
Changes Worth Mentioning
Release notes can be found on GitHub at rabbitmq-server/release-notes.
Core Broker
Bug Fixes
-
Quorum queue validation on startup was too strict and prevented upgrades from certain older versions from succeeding.
This validation has been reduced from an error to a warning.
Enhancements
-
Stream replication port range now can be configured via
rabbitmq.conf
:stream.replication.port_range.min = 4000 stream.replication.port_range.max = 4600
GitHub issue: #11774
Dependency Changes
- Ra was upgraded to
2.13.5
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.13.6.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 4.0.0-beta.2
RabbitMQ 4.0.0-beta.2
is a preview of a new major release.
Starting June 1st, 2024, community support for this series will only be provided to regularly contributing users and those who hold a valid commercial support license.
Highlights
Some key improvements in this release are listed below.
- Khepri, an alternative schema data store developed to replace Mnesia,
has matured - AMQP 1.0 is now a core protocol that is always enabled. Its plugin is now a no-op that only exists to simplify upgrades.
- The AMQP 1.0 implementation is now significantly more efficient: its peak throughput is more than double than that of 3.13.x
on some workloads - AMQP 1.0 clients now can manage topologies similarly to how AMQP 0-9-1 clients do it
- The AMQP 1.0 convention (address format) used for interacting with with AMQP 0-9-1 entities is now easier to reason about
- Mirroring (replication) of classic queues was removed after several years of deprecation. For replicated messaging data types,
use quorum queues and/or streams. Non-replicated classic queues remain and their development continues - Classic queue storage efficiency improvements, in particular recovery time and storage of multi-MiB messages
- Nodes with multiple enabled plugins and little on disk data to recover now start up to 20-30% faster
- CQv1, the original classic queue storage layer, was removed except for the part that's necessary for upgrades
- Several I/O-related metrics are dropped, they should be monitored at the infrastructure and kernel layers
See Compatibility Notes below to learn about breaking or potentially breaking changes in this release.
Release Artifacts
RabbitMQ releases are distributed via GitHub.
Debian and RPM packages are available via Cloudsmith mirrors.
Community Docker image, Chocolatey package, and the Homebrew formula
are other installation options. They are updated with a delay.
Erlang/OTP Compatibility Notes
This release requires Erlang 26.2.
Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision latest patch versions of Erlang 26.x.
Upgrading to 4.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 only supports upgrades from 3.13.x
.
This release requires all feature flags in the 3.x series (specifically 3.13.x
) to be enabled before upgrading,
there is no upgrade path from 3.12.14 (or a later patch release) straight to 4.0.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.13.x.
Mixed version cluster compatibility
RabbitMQ 4.0.0 nodes can run alongside 3.13.x
nodes. 4.0.x
-specific features can only be made available when all nodes in the cluster
upgrade to 4.0.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 will be covered in future updates.
Once all nodes are upgraded to 4.0.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).
Recommended Post-upgrade Procedures
TBD
Changes Worth Mentioning
TBD
Dependency Changes
- Ra was upgraded to
2.13.3
- Khepri was upgraded to
0.14.0
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-4.0.0-beta.2.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 3.13.5
RabbitMQ 3.13.5
is a maintenance release in the 3.13.x
release series.
Please skip this release and upgrade straight to 3.13.6
or a later version (if available).
Starting June 1st, 2024, community support for this series will only be provided to regularly contributing users and those
who hold a valid commercial support license.
Please refer to the upgrade section from the 3.13.0 release notes
if upgrading from a version prior to 3.13.0.
This release requires Erlang 26 and supports Erlang versions up to 26.2.x
.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.
Minimum Supported Erlang Version
As of 3.13.0, RabbitMQ requires Erlang 26. Nodes will fail to start on older Erlang releases.
Users upgrading from 3.12.x (or older releases) on Erlang 25 to 3.13.x on Erlang 26
(both RabbitMQ and Erlang are upgraded at the same time) must consult
the v3.12.0 release notes and v3.13.0 release notes first.
Changes Worth Mentioning
Release notes can be found on GitHub at rabbitmq-server/release-notes.
Core Broker
Bug Fixes
-
Quorum queue replicas could fail to recover in certain scenarios.
GitHub issue: #11769
-
Safer AMQP 0-9-1 to AMQP 1.0 (the internal message format) conversion for longer string values.
GitHub issue: #11737
-
When a message that contained an
x-deaths
dead-lettering header was republished "as is" by a client,
thetime
field in the dead lettering events was not correctly converted for AMQP 0-9-1 clients.GitHub issue: #11608
-
Direct Reply-to failed with an exception when firehose tracing was enabled.
GitHub issue: #11666
CLI Tools
Bug Fixes
-
rabbitmqctl export_definitions
failed if cluster contained custom federation upstream set definitions.GitHub issue: #11612
MQTT Plugin
Bug Fixes
-
An abrupt client TCP connection closure could result in a spike in that connection's memory footprint.
GitHub issue: #11683
Shovel Plugin
Enhancements
etcd Peer Discovery Plugin
Bug Fixes
-
Nodes now register themselves before running peer discovery, reducing the probability of
first (usually) two nodes to boot potentially forming two initial clusters.
Consul Peer Discovery Plugin
Bug Fixes
-
Nodes now register themselves before running peer discovery, reducing the probability of
first (usually) two nodes to boot potentially forming two initial clusters.
AWS Peer Discovery Plugin
Enhancements
-
Forward compatibility: handle AWS API responses that use empty HTTP response bodies.
Contributed by @SimonUnge.
GitHub issue: #11722
Dependency Changes
- Ra was upgraded to
2.13.3
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.13.5.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 4.0.0-beta.1
RabbitMQ 4.0.0-beta.1
is a preview of a new major release.
Starting June 1st, 2024, community support for this series will only be provided to regularly contributing users and those who hold a valid commercial support license.
Highlights
Some key improvements in this release are listed below.
- Khepri, an alternative schema data store developed to replace Mnesia, has matured
- AMQP 1.0 is now a core protocol that is always enabled. Its plugin is now a no-op that only exists to simplify upgrades.
- The AMQP 1.0 implementation is now significantly more efficient: its peak throughput is more than double than that of 3.13.x on some workloads
- AMQP 1.0 clients now can manage topologies similarly to how AMQP 0-9-1 clients do it
- The AMQP 1.0 convention (address format) used for interacting with with AMQP 0-9-1 entities is now easier to reason about
- Mirroring (replication) of classic queues was removed after several years of deprecation. For replicated messaging data types,
use quorum queues and/or streams. Non-replicated classic queues remain and their development continues - Classic queue storage efficiency improvements, in particular recovery time and storage of multi-MiB messages
- Nodes with multiple enabled plugins and little on disk data to recover now start up to 20-30% faster
- CQv1, the original classic queue storage layer, was removed except for the part that's necessary for upgrades
- Several I/O-related metrics are dropped, they should be monitored at the infrastructure and kernel layers
See Compatibility Notes below to learn about breaking or potentially breaking changes in this release.
Release Artifacts
RabbitMQ releases are distributed via GitHub.
Debian and RPM packages are available via Cloudsmith mirrors.
Community Docker image, Chocolatey package, and the Homebrew formula
are other installation options. They are updated with a delay.
Erlang/OTP Compatibility Notes
This release requires Erlang 26.2.
Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision latest patch versions of Erlang 26.x.
Upgrading to 4.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 only supports upgrades from 3.13.x
.
This release requires all feature flags in the 3.x series (specifically 3.13.x
) to be enabled before upgrading,
there is no upgrade path from 3.12.14 (or a later patch release) straight to 4.0.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.13.x.
Mixed version cluster compatibility
RabbitMQ 4.0.0 nodes can run alongside 3.13.x
nodes. 4.0.x
-specific features can only be made available when all nodes in the cluster
upgrade to 4.0.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 will be covered in future updates.
Once all nodes are upgraded to 4.0.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).
Recommended Post-upgrade Procedures
TBD
Changes Worth Mentioning
TBD
Dependency Changes
- Ra was upgraded to
2.13.1
- Khepri was upgraded to
0.14.0
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-4.0.0-beta.1.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 3.13.4
RabbitMQ 3.13.4
is a maintenance release in the 3.13.x
release series.
Please skip this release and upgrade straight to 3.13.6
or a later version (if available).
Starting June 1st, 2024, community support for this series will only be provided to regularly contributing users and those
who hold a valid commercial support license.
Please refer to the upgrade section from the 3.13.0 release notes
if upgrading from a version prior to 3.13.0.
This release requires Erlang 26 and supports Erlang versions up to 26.2.x
.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.
Minimum Supported Erlang Version
As of 3.13.0, RabbitMQ requires Erlang 26. Nodes will fail to start on older Erlang releases.
Users upgrading from 3.12.x (or older releases) on Erlang 25 to 3.13.x on Erlang 26
(both RabbitMQ and Erlang are upgraded at the same time) must consult
the v3.12.0 release notes and v3.13.0 release notes first.
Changes Worth Mentioning
Release notes can be found on GitHub at rabbitmq-server/release-notes.
Core Broker
Bug Fixes
-
A rolling upgrade from
3.12.14
to3.13.x
could run into an exception.GitHub issue: #11380
-
When an existing virtual host was re-imported from a definitions file,
its default queue type (DQT) was cleared (reset) if that field was missing in the imported
definitions.Now the existing DQT is preserved.
GitHub issue: #11457
-
When a queue was declared without an explicitly provided
x-queue-type
but a default
queue type (DQT) set (for its virtual host), its redeclaration did not consider
the DQT during the property equivalence check stage.GitHub issue: #11541
-
Feature flag controller could run into a deadlock in some upgrade scenarios.
GitHub issue: #11414
-
In mixed
3.13.x
and3.12.x
clusters, when a Direct Reply-to client (the app that initiates requests)
was connected to the3.13
node and the server (the app that responds) was connected to the3.12
node,
the response was lost due to a message format conversion exception.GitHub issue: #11401
Enhancements
-
In some parallel cluster formation scenarios where definitions were imported on node boot,
the virtual hosts created by the import can only be started on a subset of nodes. This is so
because not all cluster peers are known at virtual host creation time.To reconcile (repair) this state, nodes will periodically check that all virtual hosts are initialized
on all cluster nodes. This happens every thirty seconds for the first five minutes
since node boot. As long as the cluster is fully formed within that amount of time,
all nodes will have performed initialization for all virtual hosts that exist.GitHub issue: #11408
-
Quorum queue leader replicas now initiate reconciliation (repair) of their
replicas, if there are any missing, more frequently, making quorum queues
more defensive in the case of (highly discouraged) grow-then-shrink upgrades.As part of this change, the CPU cost of reconciliation was reduced, now accounting
for less than 1% of the CPU with 10K quorum queues in some test environments.Contributed by @SimonUnge.
GitHub issue: #11029
-
In the case where the
vhost_max
node limit is reached, the node will log specific errors
when a new virtual host is (unsuccessfully) added.Contributed by @SimonUnge.
GitHub issue: #11589
-
Elapsed time in the logs is now measured using monotonic time.
GitHub issue: #11396
CLI Tools
Bug Fixes
-
rabbitmq-diagnostics check_if_node_is_quorum_critical
could report a false positive
when some quorum queue replcas where very recently added or very recently restarted.GitHub issue: #11524
-
rabbitmqctl list_unresponsive_queues
ran into an exception if there were connected MQTT clients
with QoS 0 subscriptions.Partially contributed by @gomoripeti.
GitHub issue: #11434
Enhancements
OAuth 2 Plugin
Enhancements
-
OpenID Connect discovery endpoint now can be overridden for identity providers with
non-standard configurations.GitHub issue: #11103
Management Plugin
Bug Fixes
-
Virtual host metadata was not included into definition files exported via the HTTP API.
GitHub issue: #10515
-
When Khepri was enabled and a majority of cluster members were down, adding a virtual host
failed with an unhelpful exception.GitHub issue: #11590
Enhancements
-
When default queue type is set on a virtual host but not for individual queues,
the exported queues will havex-queue-type
set to the default type in the
exported definitions document.GitHub issue: #10515
-
Management UI will now display the number of cores available to the node.
GitHub issue: #11382
-
OAuth 2-specific JavaScript files are now only loaded if the OAuth 2 plugin is enabled
on the node.GitHub issue: #11421
HTTP AuthN/AuthZ Backend Plugin
Enhancements
-
TLS-related settings, in particular related to peer certificate chain verification, now can be
configured for this plugin:auth_http.ssl_options.verify = verify_none auth_http.ssl_options.fail_if_no_peer_cert = false
Please remember that disabling peer certificate chain verification makes the system
less secure and susceptible to Man-in-the-Middle attacks.
Consider enabling the verification in production systems when possible.GitHub issue: #10281
etcd Peer Discovery Plugin
Bug Fixes
-
The plugin failed to extract discovered nodes name correctly in earlier
3.13.x
releases.GitHub issue: #11445
Tracing Plugin
Enhancements
-
tracing.dir
,tracing.username
andtracing.password
are the three Tracing plugin
settings that can be set viarabbitmq.conf
.GitHub issue: #11554
Dependency Changes
- Ra was upgraded to
2.11.0
- Osiris was upgraded to
1.8.2
- Jose was upgraded to
1.11.10
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.13.4.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 3.13.3
RabbitMQ 3.13.3
is a maintenance release in the 3.13.x
release series.
Please skip this release and upgrade straight to 3.13.6
or a later version (if available).
Starting June 1st, 2024, community support for this series will only be provided to regularly contributing users and those
who hold a valid commercial support license.
Please refer to the upgrade section from the 3.13.0 release notes
if upgrading from a version prior to 3.13.0.
This release requires Erlang 26 and supports Erlang versions up to 26.2.x
.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.
Minimum Supported Erlang Version
As of 3.13.0, RabbitMQ requires Erlang 26. Nodes will fail to start on older Erlang releases.
Users upgrading from 3.12.x (or older releases) on Erlang 25 to 3.13.x on Erlang 26
(both RabbitMQ and Erlang are upgraded at the same time) must consult
the v3.12.0 release notes and v3.13.0 release notes first.
Changes Worth Mentioning
Release notes can be found on GitHub at rabbitmq-server/release-notes.
Core Broker
Bug Fixes
-
Fixes an exception in classic queue message store that produced large scary looking log entries.
No data was lost as a result of the exception but clients could run into a channel error.GitHub issue: #11292
-
Corrected several 3.13-specific issues related to how the
x-death
headers are populated during dead lettering.GitHub issues: #11160, #11159, #11174, #11339, #10709, #11331
-
Per-virtual host queue (and stream) limit is now enforced for AMQP 1.0, MQTT, RabbitMQ Stream Protocol and STOMP as well as AMQP 0-9-1.
Contributed by @SimonUnge.
GitHub issue: #11293
-
Periodic replica reconciliation of quorum queues now reacts to node shutdown in cluster where Khepri is enabled.
Contributed by @SimonUnge.
GitHub issue: #11134
-
Declaration of an exchange of a non-existent type will now report a more suitable "precondition failed"
error to the client.Contributed by @carlhoerberg.
GitHub issue: #11215
-
Avoids a scary looking log message during node shutdown in certain plugin configurations.
GitHub issue: #11323
Enhancements
-
x-death
headers used to provide metadata about dead-lettering are now included
for messages consumed from a stream.GitHub issue: #11173
-
Classic queue message store recovery was optimized (peak memory footprint-wise) for cases where large (multiple MiB in size) messages
were routed to multiple queues.Contributed by @gomoripeti.
GitHub issue: #11072
-
Besides the previously existing option of configuring default queue type per virtual host,
there is now a "global" per node default that can be set viarabbitmq.conf
:# Changes default queue type for all clients connected to the configured node # to quorum queues. # This is just an example, not all queues should be quorum queues. # See https://www.rabbitmq.com/docs/quorum-queues to learn more. default_queue_type = quorum
Contributed by @SimonUnge.
GitHub issue: #11163
-
When a virtual host process stops, fails or is restarted, a clear message will now be logged.
GitHub issue: #11276
CLI Tools
Bug Fixes
-
rabbitmq-plugins list
incorrectly marked disabled plugins as "pending an upgrade".Partially contributed by @gomoripeti.
GitHub issue: #11198
-
rabbitmqctl check_if_any_deprecated_features_are_used
could run into an exception.Partially contributed by @metron2.
GitHub issue: #11194
Prometheus Plugin
Enhancements
-
A new Prometheus-exposed metric,
rabbit_stream_segments
, indicates how many stream segment files
there are on the target node.Contributed by @markus812498.
GitHub issue: #11325
Management Plugin
Bug Fixes
-
After signing out of management UI, the page was not refreshed to reflect updated login (session) status.
GitHub issue: #11224
Shovel Management Plugin
Bug Fixes
-
rabbitmqctl delete_shovel
is now more effective at deleting Shovels that
cannot start (for example, because they cannot connect using the configured URIs) and
repeatedly fail, get restarted, fail again, get restarted, and so on.GitHub issue: #11324
-
fail_if_no_peer_cert
, a server-side TLS setting, was removed from Shovel URI examples.
Erlang 26's TLS implementation will refuse to accept it as a client-side setting whereas
previously it was quietly ignored.Contributed by @womblep.
GitHub issue: #11318
Dependency Changes
None in this release.
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.13.3.tar.xz
instead of the source tarball produced by GitHub.
RabbitMQ 3.12.14
RabbitMQ 3.12.14
is a maintenance release in the 3.12.x
release series.
This release goes out of community support on June 1st, 2024.
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.2.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 Broker
Bug Fixes
-
Quorum queues are now more defensive when acquiring file handles.
GitHub issue: #10587
Enhancements
-
There is now a way to configure default queue type globally (that is, not per virtual host)
inrabbitmq.conf
:# Built-in type aliases are "quorum", "classic", "stream" default_queue_type = quorum
Contributed by @SimonUnge.
GitHub issue: #11165
-
channel_max_per_node
is a new per-node limit that allows to put a cap on the number
of AMQP 0-9-1 channels that can be concurrently open by all clients connected to a node:# rabbitmq.conf channel_max_per_node = 5000
This is a guardrail mean to protect nodes from application-level channel leaks.
Contributed by @illotum.
GitHub issue: #10754
-
Definition import did not handle a scenario where some virtual hosts did not have
the default queue type metadata key set.GitHub issue: #10897
AMQP 1.0 Plugin
Bug Fixes
-
Safer AMQP 1.0 => AMQP 0-9-1 message durability property conversion.
GitHub issue: #10568
Management Plugin
Bug Fixes
-
When a tab (Connections, Queues and Streams, etc) is switched, a table configuration pane
from the previously selected tab is now hidden.Contributed by @ackepenek.
GitHub issue: #10799
JMS Topic Exchange Plugin
Enhancements
-
The plugin now stores its state on multiple nodes.
GitHub issue: #11098
Dependency Changes
cowboy
was updated to2.12.0
Source Code Archives
To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.12.14.tar.xz
instead of the source tarball produced by GitHub.