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.

RabbitMQ 3.13.2

RabbitMQ 3.13.2 is a maintenance release in the 3.13.x release series.
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

• Several Quorum queues WAL and segment file operations are now more resilient to certain filesystem operation failures.

  GitHub issue: #11113

• Classic queues v2 could run into an exception after a node restart.

  GitHub issue: #11111

• Peer discovery failed in some IPv6-only environments. This behavior was new in 3.13.x.

  GitHub issue: #10728

• rabbitmqctl stop_app is now faster, in particular for nodes that are not under significant load.

  GitHub issue: #11075

• x-death counter was not incremented for messages that expired due to message TTL.
  This behavior was new in 3.13.x.

  GitHub issue: #10709

• Quorum queue replica removal now more resilient in clusters under close to peak load,
  a condition that can trigger timeouts for certain operations involving multiple nodes.

  GitHub issue: #11065

• rabbitmq-server (the shell script) now propagetes the exit code from the runtime process.

  Contributed by @giner.

  GitHub issue: #10819

Enhancements

• Definition import did not handle a scenario where some virtual hosts did not have
  the default queue type metadata key set.

  GitHub issue: #10897

• When a virtual host is deleted, several more internal events are emitted: for example,
  the events related to removal of user permissions and runtime parameters associated
  with the virtual host.

  GitHub issue: #11077

CLI Tools

Bug Fixes

• rabbitmqctl list_unresponsive_queues now supports the (queue) type column.

  Contributed by @aaron-seo.

  GitHub issue: #11081

MQTT Plugin

Bug Fixes

• MQTT clients that did not configure a will (message) delay interval could run into
  an exception due to an unnecessary permission check on the will target.

  GitHub issue: #11024

• Messages published by MQTT clients were missing the timestamp_in_ms (the more precise header).
  This behavior was new in 3.13.x.

  GitHub issue: #10925

• Messages published using QoS 0 were unintentionally marked as durable internally.

  GitHub issue: #11012

Management Plugin

Bug Fixes

• GET /api/queues/{vhost}/{name} could return duplicate keys for quorum queues.

  GitHub issue: #10929

• Several endpoints responded with a 500 instead of a 404 when target virtual host
  was non-existent.

  Partially contributed by @LoisSotoLopez.

  GitHub issue: #10901

OAuth 2 AuthN/AuthZ Plugin

Enhancements

• The OpenID Connect RP-Initiated Logout feature is now only used if the identity provider service
  lists it as supported.

  GitHub issue: #11067

Kubernetes Peer Discovery Plugin

Enhancements

• More TLS client settings now can be configured:

  cluster_formation.k8s.tls.cacertfile = /path/to/kubernetes/api/ca/certificate.pem
  cluster_formation.k8s.tls.certfile = /path/to/client/tls/certificate.pem
  cluster_formation.k8s.tls.keyfile = /path/to/client/tls/private_key.pem
  
  cluster_formation.k8s.tls.verify = verify_peer
  cluster_formation.k8s.tls.fail_if_no_peer_cert = true
  

  GitHub issue: #10916

JMS Topic Exchange Plugin

Enhancements

• The plugin now stores its state on multiple nodes.

  GitHub issue: #11091

Shovel Plugin

Bug Fixes

• Shovel metrics and internal state are now deleted when their shovel is, regardless of what node
  it was hosted on and what node was targeted by the deleting (CLI or HTTP API) operation.

  GitHub issue: #11101

• rabbitmqctl list_shovels CLI command now will list shovels running on all cluster nodes
  and not just the target node.

  GitHub issue: #11119

Dependency Changes

• ra was updated to 2.10.0

Source Code Archives

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