RabbitMQ 4.0.0-beta.6

RabbitMQ 4.0.0-beta.6 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
• 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.

Settings cluster_formation.randomized_startup_delay_range.* were Removed

The following two deprecated rabbitmq.conf settings were removed:

cluster_formation.randomized_startup_delay_range.min
cluster_formation.randomized_startup_delay_range.max

RabbitMQ 4.0 will fail to boot if these settings are configured in rabbitmq.conf.

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
repositories maintained by the RabbitMQ Core Team.

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...

RabbitMQ 3.13.7

RabbitMQ 3.13.7 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

• Streams recover better from certain node process failures that may leave behind orphaned segment files
  (that is, segment files that do not have a corresponding index file) or index files without a corresponding
  segment file.

  Kudos to @sysupbda for providing detailed reproduction steps and verifying the fix in the affected environment.

  GitHub issue: #12073

• Config file peer discovery now logs warnings for certain common user mistakes.

  GitHub issues: #11586, #11898

• Queue declaration operations now return more useful errors when Khepri is enabled and there's only a minority
  of nodes online.

  GitHub issues: #12020, #11991

• Logging is now more defensive around exception handling. Previously a (very rare) logger exception could
  lead to the amq.rabbitmq.log handler and exchange to be removed.

  Contributed by @gomoripeti.

  GitHub issue: #12107

• rabbitmq-upgrade revive unintentionally tried to perform operations on replicas that are not local to the node.
  This could result in an exceptions some of which were not handled and the command failed.
  Re-running the command usually helped.

  GitHub issue: #12038

Enhancements

• Enabling an experimental feature flag now involves an explicit confirmation.

  GitHub issue: #12059

• Khepri projections are registered in a safer manner during node boot.

  GitHub issue: #11837

MQTT

Bug Fixes

• Clients that use JWT tokens are now disconnected when their token expires. Previously all newly attempted
  operations with an expired token would be rejected but a completely passive connection was not closed.

  GitHub issue: #11869

Enhancements

• Connection that provide incorrect credentials now closed with a delay, just like for several
  other protocols supported by RabbitMQ, as a throttling mechanism.

  GitHub issue: #11906

CLI Tools

Bug Fixes

• When the Khepri feature flag is not enabled, rabbitmq-diagnostics metadata_store_status will not try to retrieve
  and display its status.

  GitHub issue: #12103

Enhancements

• rabbitmq-upgrade await_quorum_plus_one now produces more log messages when the operation times out.
  When Khepri is enabled, it now also treats Khepri as a critical Raft-based component that may depend on replica quorum
  just like queues and streams do.

  GitHub issue: #12117

Management Plugin

Bug Fixes

• When no virtual host limits are set, the limits collection was returned as a JSON array (and not a JSON object)
  by GET /api/vhost-limits.

  GitHub issue: #12084

Enhancements

• GET /api/queues/quorum/{vhost}/{name}/status is a new endpoint that allows clients to retrieve several key quorum queue
  replica and Raft metrics.

  Contributed by @SimonUnge.

  GitHub issue: #12072

Shovel Plugin

Bug Fixes

• GET /api/shovels/{vhost}/{name} now correctly returns a single shovel instead of all shovels in the target
  virtual host.

  GitHub issue: #12040

Consistent Hashing Exchange Plugin

Bug Fixes

• For an exchange declared with a hash-header, publishing failed with an exception when the client (usually unintentionally)
  did not set that header.

  GitHub issue: #11808

Dependency Changes

• Osiris was upgraded to 1.8.3
• Cuttlefish was upgraded to 3.4.0
• observer_cli was upgraded to 1.7.5

Source Code Archives

To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.13.7.tar.xz
instead of the source tarball produced by GitHub.

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.