RabbitMQ 3.11.28

RabbitMQ 3.11.28 is a maintenance release in the 3.11.x release series.

This release series is out of community support.

Please refer to the upgrade section from v3.11.0 release notes
if upgrading from a version prior to 3.11.0.

This release requires Erlang 25 and supports Erlang versions up to 25.3.x.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.

Minimum Supported Erlang Version

As of 3.11.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases.

Erlang 25 as our new baseline means much improved performance on ARM64 architectures, profiling with flame graphs
across all architectures, and the most recent TLS 1.3 implementation available to all RabbitMQ 3.11 users.

Changes Worth Mentioning

Release notes can be found on GitHub at rabbitmq-server/release-notes.

Prometheus Plugin

Enhancements

• Metric label values now escape certain non-ASCII characters.

  Contributed by @gomoripeti (CloudAMQP).

  GitHub issue: #10196

Management Plugin

Bug Fixes

• Reverted a change to DELETE /api/queues/{vhost}/{name} that allowed removal of
  exclusive queues and introduced unexpected side effects.

  GitHub issue: #10189

• Avoid log noise when an HTTP API request is issued against a booting
  or very freshly booted node.

  Contributed by @gomoripeti (CloudAMQP).

  GitHub issue: #10183

AWS Peer Discovery Plugin

Enhancements

• Type spec and test corrections.

  Contributed by @illotum (AWS).

  GitHub issue: #10133

Dependency Upgrades

None in this release.

Source Code Archives

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

RabbitMQ 3.13.0-rc.3

RabbitMQ 3.13.0-rc.3

RabbitMQ 3.13.0-rc.3 is a candidate of a new feature release.

Highlights

This release includes several new features and optimizations.

The user-facing areas that have seen the biggest improvements in this release are

• Khepri now can be used as an alternative schema data store
  in RabbitMQ, replacing Mnesia
• Support for consumer-side stream filtering
• MQTTv5 support
• A new common message container format used internally, based on the AMQP 1.0 message container format
• Improved classic non-mirrored queue performance with message sizes larger than
  4 KiB (or a different customized CQ index embedding threshold)
• Classic queues use version 2 of the storage implementation (CQv2).
  This should significantly improve performance of non-mirrored classic queues

See Compatibility Notes below to learn about breaking or potentially breaking changes in this release.

Release Artifacts

RabbitMQ preview releases are distributed via GitHub.

Community Docker image is another installation option
for previews. It is updated with a delay (usually a few days).

Erlang/OTP Compatibility Notes

This release requires Erlang 26.0 or later.

Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision latest patch versions of Erlang 26.x.

Upgrading to 3.13

Documentation guides on upgrades

See the Upgrading guide for documentation on upgrades and RabbitMQ change log
for release notes of other releases.

Note that since 3.12.0 requires all feature flags to be enabled before upgrading,
there is no upgrade path from from 3.11.24 (or a later patch release) straight to 3.13.0.

Required Feature Flags

This release does not graduate any feature flags.

However, all users are highly encouraged to enable all feature flags before upgrading to this release from
3.12.x.

Mixed version cluster compatibility

RabbitMQ 3.13.0 nodes can run alongside 3.12.x nodes. 3.13.x-specific features can only be made available when all nodes in the cluster
upgrade to 3.13.0 or a later patch release in the new series.

While operating in mixed version mode, some aspects of the system may not behave as expected. The list of known behavior changes is covered below.
Once all nodes are upgraded to 3.13.0, these irregularities will go away.

Mixed version clusters are a mechanism that allows rolling upgrade and are not meant to be run for extended
periods of time (no more than a few hours).

Compatibility Notes

This release includes a few potentially breaking changes&

Minimum Supported Erlang Version

Starting with this release, RabbitMQ requires Erlang 26.0 or later versions. Nodes will fail to start
on older Erlang releases.

Client Library Compatibility

Client libraries that were compatible with RabbitMQ 3.12.x will be compatible with 3.13.0.
RabbitMQ Stream Protocol clients must be upgraded to use the stream filtering feature
introduced in this release.

Consistency Model and Schema Modification Visibility Guarantees of Khepri and Mnesia

Khepri has an important difference from Mnesia when it comes to schema modifications such as queue
or stream declarations, or binding declarations. These changes won't be noticeable with many workloads
but can affect some, in particular, certain integration tests.

Consider two scenarios, A and B.

Scenario A

There is only one client. The client performs the following steps:

1. It declares a queue Q
2. It binds Q to an exchange X
3. It publishes a message M to the exchange X
4. It expects the message to be routed to queue Q
5. It consumes the message

In this scenario, there should be no observable difference in behavior. Client's expectations
will be met.

Scenario B

There are two clients, One and Two, connected to nodes R1 and R3, and using the same virtual host.
Node R2 has no client connections.

Client One performs the following steps:

1. It declares a queue Q
2. It binds Q to an exchange X
3. It gets a queue declaration confirmation back
4. It notifies client 2 or client 2 implicitly finds out that it has finished the steps above (for example, in an integration test)
5. Client Two publishes a message M to X
6. Clients One and Two expect the message to be routed to Q

In this scenario, on step three Mnesia would return when all cluster nodes have committed an update.
Khepri, however, will return when a majority of nodes, including the node handling Client One's operations,
have returned.

This may include nodes R1 and R2 but not node R3, meaning that message M published by Client Two connected to node R3
in the above example is not guaranteed not be routed.

Once all schema changes propagate to node R3, Client Two's subsequent
publishes on node R3 will be guaranteed to be routed.

This trade-off of a Raft-based system that assume that a write accepted by a majority of nodes
can be considered a succeess.

Workaround Strategies

To satisfy Client Two's expectations in scenario B Khepri could perform consistent (involving a majority of replicas)
queries of bindings when routing messages but that would have a significant impact on throughput
of certain protocols (such as MQTT) and exchange/destination types (anything that resembles a topic exchange in AMQP 0-9-1).

Applications that rely on multiple connections that depend on a shared topology have
several coping strategies.

If an application uses two or more connections to different nodes, it can
declare its topology on boot and then injecting a short pause (1-2 seconds) before proceeding with
other operations.

Applications that rely on dynamic topologies can switch to use a "static" set of
exchanges and bindings.

Application components that do not need to use a shared topology can each configure
its own queues/streams/bindings.

Test suites that use multiple connections to different nodes can choose to use just one connection or
connect to the same node, or inject a pause, or await a certain condition that indicates that the topology
is in place.

Management Plugin and HTTP API

GET /api/queues` HTTP API endpoint has dropped several rarely used metrics, resulting in 25% in traffic saving.

MQTT Plugin

mqtt.subscription_ttl (in milliseconds) configuration setting was replaced with mqtt.max_session_expiry_interval_seconds (in seconds).
A 3.13 RabbitMQ node will fail to boot if the old configuration setting is set.
For example, if you set mqtt.subscription_ttl = 3600000 (1 hour) prior to 3.13, replace that setting with mqtt.max_session_expiry_interval_seconds = 3600 (1 hour) in 3.13.

rabbitmqctl node_health_check is Now a No-Op

rabbitmqctl node_health_check has been deprecated for over three years
and is now an no-op (does nothing).

See the Health Checks section in the monitoring guide
to find out what modern alternatives are available.

openSUSE Leap Package is not Provided

An openSUSE Leap package will not be provided with this release of RabbitMQ.

This release requires Erlang 26 and there is an Erlang 26 package available from Erlang Factory
but the package depends on glibc 2.34, and all currently available openSUSE Leap releases
(up to 15.5) ship with 2.31 at most.

Team RabbitMQ would like to continue building a openSUSE Leap package when a Leap 15.5-compatible Erlang 26
package becomes publicly available.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome in GitHub Discussions or
on our community Discord.

Changes Worth Mentioning

Release notes are kept under rabbitmq-server/release-notes.

Core Server

Enhancements

• Khepri now can be used as an alternative schema data store
  in RabbitMQ, by enabling a feature flag:

  rabbitmqctl enable_feature_flag khepri_db

  In practical terms this means that it will be possible to swap Mnesia for a Raft-based data store
  that will predictably recover from network partitions and node failures, the same way quorum queues
  and streams already do. At the same time, this means
  that RabbitMQ clusters now must have a majority of nodes online at all times, or all client operations will be refused.

  Like quorum queues and streams, Khepri uses RabbitMQ's Raft implementation under the hood. With Khepri enabled, all key modern features
  of RabbitMQ will use the same fundamental approach to recovery from failures, relying on a library that passes a Jepsen test suite.

...

RabbitMQ 3.11.27

RabbitMQ 3.11.27 is a maintenance release in the 3.11.x release series.

This release series is out of community support.

Please refer to the upgrade section from v3.11.0 release notes
if upgrading from a version prior to 3.11.0.

This release requires Erlang 25 and supports Erlang versions up to 25.3.x.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.

Minimum Supported Erlang Version

As of 3.11.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases.

Erlang 25 as our new baseline means much improved performance on ARM64 architectures, profiling with flame graphs
across all architectures, and the most recent TLS 1.3 implementation available to all RabbitMQ 3.11 users.

Changes Worth Mentioning

Release notes can be found on GitHub at rabbitmq-server/release-notes.

Core Broker

Bug Fixes

• Avoids a rare exception that could stop TCP socket writes on a client connection.

  GitHub issues: #9991, #9803

Enhancements

• Definition files that are virtual host-specific cannot be imported on boot. Such files will now be
  detected early and the import process will terminate after logging a more informative message.

  Previous the import process would run into an obscure exception.

  GitHub issues: #10068, #10086

Shovel Plugin

Bug Fixes

• Avoids two Shovels being started after an upgrade from 3.11.25 or older versions.

  Two Shovels running concurrently would still transfer messages but because they act as
  competing consumers (and publishers), this affected message ordering in the target queue.

  Contributed by @gomoripeti (CloudAMQP).

  GitHub issues: #9965, #10080

Management Plugin

Bug Fixes

• DELETE /api/policies/{vhost}/{policy} returned a 500 response instead of a 404 one
  when target virtual host did not exist.

  GitHub issue: #9983

Dependency Upgrades

None in this release.

Source Code Archives

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

RabbitMQ 3.12.10

RabbitMQ 3.12.10 is a maintenance release in the 3.12.x release series.

Please refer to the upgrade section from the 3.12.0 release notes
if upgrading from a version prior to 3.12.0.

This release requires Erlang 25 and supports Erlang versions up to 26.1.x.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.

Minimum Supported Erlang Version

As of 3.12.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases.

Users upgrading from 3.11.x (or older releases) on Erlang 25 to 3.12.x on Erlang 26
(both RabbitMQ and Erlang are upgraded at the same time) must consult
the v3.12.0 release notes first.

Changes Worth Mentioning

Release notes can be found on GitHub at rabbitmq-server/release-notes.

Shovel Plugin

Enhancements

• Avoids two Shovels being started after an upgrade from 3.12.6 or older versions.

  Two Shovels running concurrently would still transfer messages but because they act as
  competing consumers (and publishers), this affected message ordering in the target queue.

  Contributed by @gomoripeti (CloudAMQP).

  GitHub issue: #9965

Dependency Upgrades

None in this release.

Source Code Archives

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

RabbitMQ 3.11.26

RabbitMQ 3.11.26 is a maintenance release in the 3.11.x release series.
This release series goes out of community support on Dec 31, 2023.

Please refer to the upgrade section from v3.11.0 release notes
if upgrading from a version prior to 3.11.0.

This release requires Erlang 25 and supports Erlang versions up to 25.3.x.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.

Minimum Supported Erlang Version

As of 3.11.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases.

Erlang 25 as our new baseline means much improved performance on ARM64 architectures, profiling with flame graphs
across all architectures, and the most recent TLS 1.3 implementation available to all RabbitMQ 3.11 users.

Changes Worth Mentioning

Release notes can be found on GitHub at rabbitmq-server/release-notes.

Core Broker

Bug Fixes

• When a topic permission was deleted, an internal event of type permission.deleted
  was emitted in some cases, instead of topic.permission.deleted.

  Investigated by @bedia.

  GitHub issue: #9937

AMQP 1.0 Plugin

Bug Fixes

• Correctly block publishing AMQP 1.0 connections when a resource alarm is in effect.

  GitHub issue: #9955

Grafana Dashboard

Enhancements

• Global counters for producers are now available in the dashboard.

  Contributed by @johanrhodin (CloudAMQP)

  GitHub issue: #9846

CLI Tools

Enhancements

• rabbitmq-diagnostics list_policies_that_match [queue name] is a new command
  that simplifies troubleshooting of policy conflicts.

  GitHub issue: #9916

Dependency Upgrades

None in this release.

Source Code Archives

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

RabbitMQ 3.12.9

RabbitMQ 3.12.9 is a maintenance release in the 3.12.x release series.

Please refer to the upgrade section from the 3.12.0 release notes
if upgrading from a version prior to 3.12.0.

This release requires Erlang 25 and supports Erlang versions up to 26.1.x.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.

Minimum Supported Erlang Version

As of 3.12.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases.

Users upgrading from 3.11.x (or older releases) on Erlang 25 to 3.12.x on Erlang 26
(both RabbitMQ and Erlang are upgraded at the same time) must consult
the v3.12.0 release notes first.

Changes Worth Mentioning

Release notes can be found on GitHub at rabbitmq-server/release-notes.

Core Broker

Bug Fixes

• When a topic permission was deleted, an internal event of type permission.deleted
  was emitted in some cases, instead of topic.permission.deleted.

  Investigated by @bedia.

  GitHub issue: #9937

Shovel Plugin

Bug Fixes

• Shovels on 3.12.8 nodes failed during a rolling cluster upgrade due to internal
  identifier format changes.

  Starting with this release, both old and new formats are supported for upgrade safety.

  GitHub issue: #9894

Grafana Dashboard

Enhancements

• Global counters for producers are now available in the dashboard.

  Contributed by @johanrhodin (CloudAMQP)

  GitHub issue: #9846

MQTT Plugin

Bug Fixes

• Avoids an unnecessary warning in the logs.

  GitHub issue: #9885

CLI Tools

Enhancements

• rabbitmq-diagnostics list_policies_that_match [queue name] is a new command
  that simplifies troubleshooting of policy conflicts.

  GitHub issue: #9916

Management Plugin

Enhancements

• Nodes that have OAuth 2 enabled now redirect the user to the original landing page (if any)
  after successful login with the IDP.

  Contributed by @dukex.

  GitHub issue: #9851

Dependency Upgrades

None in this release.

Source Code Archives

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

RabbitMQ 3.13.0-rc.2

RabbitMQ 3.13.0-rc.2

RabbitMQ 3.13.0-rc.2 is a candidate of a new feature release.

Highlights

This release includes several new features and optimizations.

The user-facing areas that have seen the biggest improvements in this release are

• Khepri now can be used as an alternative schema data store
  in RabbitMQ, replacing Mnesia
• Support for consumer-side stream filtering
• MQTTv5 support
• A new common message container format used internally, based on the AMQP 1.0 message container format
• Improved classic non-mirrored queue performance with message sizes larger than
  4 KiB (or a different customized CQ index embedding threshold)
• Classic queues use version 2 of the storage implementation (CQv2).
  This should significantly improve performance of non-mirrored classic queues

See Compatibility Notes below to learn about breaking or potentially breaking changes in this release.

Release Artifacts

RabbitMQ preview releases are distributed via GitHub.

Community Docker image is another installation option
for previews. It is updated with a delay (usually a few days).

Erlang/OTP Compatibility Notes

This release requires Erlang 26.0 or later.

Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision latest patch versions of Erlang 26.x.

Upgrading to 3.13

Documentation guides on upgrades

See the Upgrading guide for documentation on upgrades and RabbitMQ change log
for release notes of other releases.

Note that since 3.12.0 requires all feature flags to be enabled before upgrading,
there is no upgrade path from from 3.11.24 (or a later patch release) straight to 3.13.0.

Required Feature Flags

This release does not graduate any feature flags.

However, all users are highly encouraged to enable all feature flags before upgrading to this release from
3.12.x.

Mixed version cluster compatibility

RabbitMQ 3.13.0 nodes can run alongside 3.12.x nodes. 3.13.x-specific features can only be made available when all nodes in the cluster
upgrade to 3.13.0 or a later patch release in the new series.

While operating in mixed version mode, some aspects of the system may not behave as expected. The list of known behavior changes is covered below.
Once all nodes are upgraded to 3.13.0, these irregularities will go away.

Mixed version clusters are a mechanism that allows rolling upgrade and are not meant to be run for extended
periods of time (no more than a few hours).

Compatibility Notes

This release includes a few potentially breaking changes&

Minimum Supported Erlang Version

Starting with this release, RabbitMQ requires Erlang 26.0 or later versions. Nodes will fail to start
on older Erlang releases.

Client Library Compatibility

Client libraries that were compatible with RabbitMQ 3.12.x will be compatible with 3.13.0.
RabbitMQ Stream Protocol clients must be upgraded to use the stream filtering feature
introduced in this release.

Consistency Model and Schema Modification Visibility Guarantees of Khepri and Mnesia

Khepri has an important difference from Mnesia when it comes to schema modifications such as queue
or stream declarations, or binding declarations. These changes won't be noticeable with many workloads
but can affect some, in particular, certain integration tests.

Consider two scenarios, A and B.

Scenario A

There is only one client. The client performs the following steps:

1. It declares a queue Q
2. It binds Q to an exchange X
3. It publishes a message M to the exchange X
4. It expects the message to be routed to queue Q
5. It consumes the message

In this scenario, there should be no observable difference in behavior. Client's expectations
will be met.

Scenario B

There are two clients, One and Two, connected to nodes R1 and R3, and using the same virtual host.
Node R2 has no client connections.

Client One performs the following steps:

1. It declares a queue Q
2. It binds Q to an exchange X
3. It gets a queue declaration confirmation back
4. It notifies client 2 or client 2 implicitly finds out that it has finished the steps above (for example, in an integration test)
5. Client Two publishes a message M to X
6. Clients One and Two expect the message to be routed to Q

In this scenario, on step three Mnesia would return when all cluster nodes have committed an update.
Khepri, however, will return when a majority of nodes, including the node handling Client One's operations,
have returned.

This may include nodes R1 and R2 but not node R3, meaning that message M published by Client Two connected to node R3
in the above example is not guaranteed not be routed.

Once all schema changes propagate to node R3, Client Two's subsequent
publishes on node R3 will be guaranteed to be routed.

This trade-off of a Raft-based system that assume that a write accepted by a majority of nodes
can be considered a succeess.

To satisfy Client Two's expectations in scenario B Khepri could beform consistent (involving a majority of replicas)
queries of bindings when routing messages but that would have a significant impact on throughput
of certain protocols (such as MQTT) and exchange/destination types (anything that resembles a topic exchange in AMQP 0-9-1).

Management Plugin and HTTP API

GET /api/queues` HTTP API endpoint has dropped several rarely used metrics, resulting in 25% in traffic saving.

MQTT Plugin

mqtt.subscription_ttl (in milliseconds) configuration setting was replaced with mqtt.max_session_expiry_interval_seconds (in seconds).
A 3.13 RabbitMQ node will fail to boot if the old configuration setting is set.
For example, if you set mqtt.subscription_ttl = 3600000 (1 hour) prior to 3.13, replace that setting with mqtt.max_session_expiry_interval_seconds = 3600 (1 hour) in 3.13.

openSUSE Leap Package is not Provided

An openSUSE Leap package will not be provided with this release of RabbitMQ.

This release requires Erlang 26 and there is an Erlang 26 package available from Erlang Factory
but the package depends on glibc 2.34, and all currently available openSUSE Leap releases
(up to 15.5) ship with 2.31 at most.

Team RabbitMQ would like to continue building a openSUSE Leap package when a Leap 15.5-compatible Erlang 26
package becomes publicly available.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome in GitHub Discussions or
on our community Discord.

Changes Worth Mentioning

Release notes are kept under rabbitmq-server/release-notes.

Core Server

Enhancements

• Khepri now can be used as an alternative schema data store
  in RabbitMQ, by enabling a feature flag:

  rabbitmqctl enable_feature_flag khepri_db

  In practical terms this means that it will be possible to swap Mnesia for a Raft-based data store
  that will predictably recover from network partitions and node failures, the same way quorum queues
  and streams already do. At the same time, this means
  that RabbitMQ clusters now must have a majority of nodes online at all times, or all client operations will be refused.

  Like quorum queues and streams, Khepri uses RabbitMQ's Raft implementation under the hood. With Khepri enabled, all key modern features
  of RabbitMQ will use the same fundamental approach to recovery from failures, relying on a library that passes a Jepsen test suite.

  Team RabbitMQ intends to make Khepri the default schema database starting with RabbitMQ 4.0.

  GitHub issue: #7206

• Messages are now internally stored using a new common heavily AMQP 1.0-influenced container format. This is a major step towards a protocol-agnostic core:
  a common format that encapsulates a sum of data types used by the protocols RabbitMQ supports, plus annotations for routng, dead-lettering state,
  and other purposes.

  AMQP 1.0, AMQP 0-9-1, MQTT and STOMP have or will adopt this internal representation in upcoming releases. RabbitMQ Stream protocol already uses the AMQP 1.0 message container
  structure internally.

  This common internal format will allow for more correct and potentially efficient multi-protocol support in RabbitMQ,
  and that most cross-protocol translation rough edges can be smoothened.

  GitHub issue: #5077

• Target quorum queue replica state is now continuously reconciled.

  When the number of online replicas of a quorum q...

RabbitMQ 3.12.8

RabbitMQ 3.12.8 is a maintenance release in the 3.12.x release series.

Please refer to the upgrade section from the 3.12.0 release notes
if upgrading from a version prior to 3.12.0.

This release requires Erlang 25 and supports Erlang versions up to 26.1.x.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.

Minimum Supported Erlang Version

As of 3.12.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases.

Users upgrading from 3.11.x (or older releases) on Erlang 25 to 3.12.x on Erlang 26
(both RabbitMQ and Erlang are upgraded at the same time) must consult
the v3.12.0 release notes first.

Changes Worth Mentioning

Release notes can be found on GitHub at rabbitmq-server/release-notes.

Core Server

Bug Fixes

• Avoids a potential exception in the autoheal partition handler.

  Contributed by @Ayanda-D.

  GitHub issue: #9818

Enhancements

• raft.segment_max_entries is now validated to prevent the value from overflowing its 16-bit segment file field.
  Maximum supported value is now 65535.

  GitHub issue: #9733

Shovel Plugin

Enhancements

• Significantly faster Shovel startup in environments where there are many of them (one thousand or more).

  GitHub issue: #9796

AMQP 1.0 Erlang Client

Enhancements

• User-provided credentials are now obfuscated using an one-off key pair generated on node boot.
  This keeps sensitive client state information from being logged by the runtime exception logger.

  GitHub issue: #9777

Dependency Upgrades

None in this release.

Source Code Archives

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

RabbitMQ 3.11.25

RabbitMQ 3.11.25 is a maintenance release in the 3.11.x release series.
This release series goes out of community support on Dec 31, 2023.

Please refer to the upgrade section from v3.11.0 release notes
if upgrading from a version prior to 3.11.0.

This release requires Erlang 25 and supports Erlang versions up to 25.3.x.
RabbitMQ and Erlang/OTP Compatibility Matrix has more details on
Erlang version requirements for RabbitMQ.

Minimum Supported Erlang Version

As of 3.11.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases.

Erlang 25 as our new baseline means much improved performance on ARM64 architectures, profiling with flame graphs
across all architectures, and the most recent TLS 1.3 implementation available to all RabbitMQ 3.11 users.

Changes Worth Mentioning

Release notes can be found on GitHub at rabbitmq-server/release-notes.

Core Server

Bug Fixes

• Avoids a potential exception in the autoheal partition handler.

  Contributed by @Ayanda-D.

  GitHub issue: #9819

Enhancements

• raft.segment_max_entries is now validated to prevent the value from overflowing its 16-bit segment file field.
  Maximum supported value is now ``65535.

  GitHub issue: #9748

Shovel Plugin

Enhancements

• Significantly faster Shovel startup in environments where there are many of them (one thousand or more).

  GitHub issue: #9800

AMQP 1.0 Erlang Client

Enhancements

• User-provided credentials are now obfuscated using an one-off key pair generated on node boot.
  This keeps sensitive client state information from being logged by the runtime exception logger.

  GitHub issue: #9778

Dependency Upgrades

None in this release.

Source Code Archives

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

RabbitMQ 3.13.0-rc.1

RabbitMQ 3.13.0-rc.1

RabbitMQ 3.13.0-rc.1 is a candidate of a new feature release.

Highlights

This release includes several new features and optimizations.

The user-facing areas that have seen the biggest improvements in this release are

• Khepri now can be used as an alternative schema data store
  in RabbitMQ, replacing Mnesia
• Support for consumer-side stream filtering
• MQTTv5 support
• A new common message container format used internally, based on the AMQP 1.0 message container format
• Improved classic non-mirrored queue performance with message sizes larger than
  4 KiB (or a different customized CQ index embedding threshold)
• Classic queues use version 2 of the storage implementation (CQv2).
  This should significantly improve performance of non-mirrored classic queues

See Compatibility Notes below to learn about breaking or potentially breaking changes in this release.

Release Artifacts

RabbitMQ preview releases are distributed via GitHub.

Community Docker image is another installation option
for previews. It is updated with a delay (usually a few days).

Erlang/OTP Compatibility Notes

This release requires Erlang 26.0 or later.

Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision latest patch versions of Erlang 26.x.

Upgrading to 3.13

Documentation guides on upgrades

See the Upgrading guide for documentation on upgrades and RabbitMQ change log
for release notes of other releases.

Note that since 3.12.0 requires all feature flags to be enabled before upgrading,
there is no upgrade path from from 3.11.24 (or a later patch release) straight to 3.13.0.

Required Feature Flags

This release does not graduate any feature flags.

However, all users are highly encouraged to enable all feature flags before upgrading to this release from
3.12.x.

Mixed version cluster compatibility

RabbitMQ 3.13.0 nodes can run alongside 3.12.x nodes. 3.13.x-specific features can only be made available when all nodes in the cluster
upgrade to 3.13.0 or a later patch release in the new series.

While operating in mixed version mode, some aspects of the system may not behave as expected. The list of known behavior changes is covered below.
Once all nodes are upgraded to 3.13.0, these irregularities will go away.

Mixed version clusters are a mechanism that allows rolling upgrade and are not meant to be run for extended
periods of time (no more than a few hours).

Compatibility Notes

TBD

Minimum Supported Erlang Version

Starting with this release, RabbitMQ requires Erlang 26.0 or later versions. Nodes will fail to start
on older Erlang releases.

Client Library Compatibility

Client libraries that were compatible with RabbitMQ 3.12.x will be compatible with 3.13.0.
RabbitMQ Stream Protocol clients must be upgraded to use the stream filtering feature
introduced in this release.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome in GitHub Discussions or
on our community Discord.

Changes Worth Mentioning

Release notes are kept under rabbitmq-server/release-notes.

Core Server

Enhancements

• Khepri now can be used as an alternative schema data store
  in RabbitMQ, by enabling a feature flag:

  rabbitmqctl enable_feature_flag khepri_db

  In practical terms this means that it will be possible to swap Mnesia for a Raft-based data store
  that will predictably recover from network partitions and node failures, the same way quorum queues
  and streams already do. At the same time, this means
  that RabbitMQ clusters now must have a majority of nodes online at all times, or all client operations will be refused.

  Like quorum queues and streams, Khepri uses RabbitMQ's Raft implementation under the hood. With Khepri enabled, all key modern features
  of RabbitMQ will use the same fundamental approach to recovery from failures, relying on a library that passes a Jepsen test suite.

  Team RabbitMQ intends to make Khepri the default schema database starting with RabbitMQ 4.0.

  GitHub issue: #7206

• Messages are now internally stored using a new common heavily AMQP 1.0-influenced container format. This is a major step towards a protocol-agnostic core:
  a common format that encapsulates a sum of data types used by the protocols RabbitMQ supports, plus annotations for routng, dead-lettering state,
  and other purposes.

  AMQP 1.0, AMQP 0-9-1, MQTT and STOMP have or will adopt this internal representation in upcoming releases. RabbitMQ Stream protocol already uses the AMQP 1.0 message container
  structure internally.

  This common internal format will allow for more correct and potentially efficient multi-protocol support in RabbitMQ,
  and that most cross-protocol translation rough edges can be smoothened.

  GitHub issue: #5077

• Target quorum queue replica state is now continuously reconciled.

  When the number of online replicas of a quorum queue goes below (or above) its target,
  new replicas will be automatically placed if enough cluster nodes are available.
  This is a more automatic version of how quorum queue replicas have originally been grown.

  For automatic shrinking of queue replicas, the user must opt in.

  Contributed by @SimonUnge (AWS).

  GitHub issue: #8218

• Reduced memory footprint, improved memory use predictability and throughput of classic queues (version 2, or CQv2).
  This particularly benefits classic queues with longer backlogs.

  Classic queue v2 (CQv2) storage implementation is now the default. It is possible to switch
  the default back to CQv1 using rabbitmq.conf:

  # uses CQv1 by default
  classic_queue.default_version = 1

  Individual queues can be declared by passing x-queue-version argument and/or through a queue-version policy.

  GitHub issue: #8308

• Non-mirrored classic queues: optimizations of storage for larger (greater than 4 kiB) messages.

  GitHub issue: #6090, #8507

• A subsystem for marking features as deprecated.

  GitHub issue: #7390

• Plugins now can register custom queue types. This means that a plugin now can provide
  a custom queue type.

  Contributed by @luos (Erlang Solutions).

  GitHub issues: #8834, #8927

Bug Fixes

This release includes all bug fixes shipped in the 3.12.x series.

• Feature flag discovery on a newly added node could discover an incomplete inventory of feature flags.

  GitHub issue: #8477

• Feature flag discovery operations will now be retried multiple times in case of network failures.

  GitHub issue: #8491

• The state of node maintenance status across the cluster is now replicated. It previously was accessible
  to all nodes but not replicated.

  GitHub issue: #9005

Management Plugin

Enhancements

• New API endpoint, GET /api/stream/{vhost}/{name}/tracking, can be used to track
  publisher and consumer offsets in a stream.

  GitHub issue: #9642

• Several rarely used queue metrics were removed to reduce inter-node data transfers
  and CPU burn during API response generation. The effects will be particularly pronounced
  for the GET /api/queues endpoint used without filtering or pagination, which can produce
  enormously large responses.

  A couple of relevant queue metrics or state fields were lifted to the top level.

  This is a potentially breaking change.

  Note that Prometheus is the recommended option for monitoring,
  not the management plugin's HTTP API.

  GitHub issues: #9437, #9578, #9633

Stream Plu...