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.

  GitHub issue: #11789, #11794

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,
  the time 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

• Improved AMQP 1.0 to AMQP 0-9-1 conversion for shovels.

  Contributed by @luos.

  GitHub issue: #10037

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.

  GitHub issues: #11647, #11646

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.

  GitHub issues: #11647, #11646

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 to 3.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 and 3.12.x clusters, when a Direct Reply-to client (the app that initiates requests)
  was connected to the 3.13 node and the server (the app that responds) was connected to the 3.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

• CLI tools now can be built with Elixir 1.17.x.

  Contributed by @VlkrS.

  GitHub issue: #11529

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 have x-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 and tracing.password are the three Tracing plugin
  settings that can be set via rabbitmq.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 via rabbitmq.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)
  in rabbitmq.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 to 2.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.