RabbitMQ 4.1.1

RabbitMQ 4.1.1 is a maintenance release in the 4.1.x release series.

It is strongly recommended that you read 4.1.0 release notes
in detail if upgrading from a version prior to 4.1.0.

Minimum Supported Erlang Version

RabbitMQ and Erlang/OTP Compatibility Matrix has more details on Erlang version requirements for RabbitMQ.

Nodes will fail to start on older Erlang releases.

Changes Worth Mentioning

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

Core Server

Enhancements

• Default queue type is now injected into virtual host metadata when the virtual host
  is created.

  This seemingly subtle change elimiantes confusing inconsistencies between different
  definition export methods and scenarios.

  GitHub issue: #13854

• Empty classic queues init faster after a clean shutdown.

  GitHub issue: #13870

Bug Fixes

• Classic queue message store compaction could fall behind (not be able to keep up with)
  very busy publishers.

  GitHub issue: #13987

• Classic queue message store could run into a rare exception
  when a message was routed to multiple queues.

  GitHub issue: #13758

• Quorum queue commit map operation order was Erlang-version specific,
  potentially leading to confusing inconsistencies between replica behaviors.

  GitHub issue: #14025

• Quorum queue failed to recover from a rare timeout during cluster formation.

  GitHub issue: #13828

• RabbitMQ could fail to log certain client connection errors for TLS-enabled
  listeners.

  GitHub issue: #13985

• Private key password could appear in certain exceptions at (failed) node boot time.

  GitHub issue: #13999, #14028

MQTT Plugin

Bug Fixes

• When an MQTTv5 client that had a QoS 0 subscription is closed, the
  transient queue that was backing it will now be deleted.

  GitHub issue: #14006

Stream Plugin

Bug Fixes

• Stream producer could run into an exception (accept_chunk_out_of_order) when a publishing filter
  was enabled.

  GitHub issue: #13897

• Stream SAC coordinator failed when a super stream consumer was added next to
  a SAC consumer.

  GitHub issue: #13835

CLI Tools

Enhancements

• rabbitmq-queues force_checkpoint [--vhost-pattern <pattern>] [--queue-pattern <pattern>]
  is a new command that forces a group of quorum queues to take a checkpoint and
  delete its on disk segment files, where possible.

  GitHub issue: #13938

Management Plugin

Enhancements

• A separate chain for authentication and authorization backends now can be used
  used exclusively for the HTTP API and the management UI.

  GitHub issue: #13819

• Reduced memory footprint of the plugin for certain workloads.

  GitHub issue: #13900

• When UI session expires, the user is redirected to the login page.

  GitHub issue: #13975

• GET /api/health/checks/below-node-connection-limit is a new health check
  that responds a 200 OK if the target node has fewer connections to the AMQP
  and AMQPS ports than the configured maximum.

  GitHub issue: #13782

• GET /api/health/checks/ready-to-serve-clients is a new health check
  that responds a 200 OK if the target node is ready to serve clients
  (booted, not above the connection limit, not in maintenance mode).

  GitHub issue: #13782

• Protocol listener health check now supports comma-separated lists of
  protocol names.

  GitHub issue: #13874

• New page for declaring super streams (partitioned streams).

  GitHub issue: #13852

OAuth 2 Plugin

Enhancements

• Select variables now can be used in scopes, for example: "rabbitmq.write:*/x-{vhost}-*/u-{sub}-*"

  GitHub issue: #14008

Shovel Plugin

Bug Fixes

• Shovels could fail to convert messages published by an AMQP 0-9-1
  client to AMQP 1.0 if the headers had a complex structure.

  GitHub issue: #13801

Dependency Changes

• ra was updated to 2.16.9
• osiris was updated to 1.8.8

Source Code Archives

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

RabbitMQ 4.1.0

RabbitMQ 4.1.0 is a new feature release.

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

Highlights

Some key improvements in this release are listed below.

Quorum Queue Throughput and Parallelism Improvements

Quorum queue log reads are now offloaded to channels (sessions, connections).

In practical terms this means improved consumer throughput, lower interference of publishers
on queue delivery rate to consumers, and improved CPU core utilization by each quorum queue
(assuming there are enough cores available to the node).

Initial Support for AMQP 1.0 Filter Expressions

Support for the properties and application-properties filters of AMQP Filter Expressions Version 1.0 Working Draft 09.

As described in the AMQP 1.0 Filter Expressions blog post,
this feature enables multiple concurrent clients each consuming only a subset of messages from a stream while maintaining message order.

Feature Flags Quality of Life Improvements

Graduated (mandatory) feature flags several minors ago has proven that they could use some user experience improvements.
For example, certain required feature flags will now be enabled on node boot when all nodes in the cluster support them.

See core server changes below as well as the GitHub project dedicated to feature flags improvements
for the complete list of related changes.

rabbitmqadmin v2

rabbitmqadmin v2 is a major revision of the
original CLI client for the RabbitMQ HTTP API.

It supports a much broader set of operations, including health checks, operations
on federation upstreams, shovels, transformations of exported definitions,
(some) Tanzu RabbitMQ HTTP API endpoints, --long-option and subcommand inference in interactive mode,
and more.

Breaking Changes and Compatibility Notes

Initial AMQP 0-9-1 Maximum Frame Size

Before a client connection can negotiate a maximum frame size (frame_max), it must authenticate
successfully. Before the authenticated phase, a special lower frame_max value
is used.

With this release, the value was increased from the original 4096 bytes to 8192
to accommodate larger JWT tokens.

Clients that do override frame_max now must use values of 8192 bytes or greater.
We recommend using the default server value of 131072: do not override the frame_max
key in rabbitmq.conf and do not set it in the application code.

Node.js amqplib Must Be Upgraded

amqplib is a popular client library that has been using
a low frame_max default of 4096. Its users must upgrade to a compatible version
(starting with 0.10.7) or explicitly use a higher frame_max.

amqplib versions older than 0.10.7 will not be able to connect to
RabbitMQ 4.1.0 and later versions due to the initial AMQP 0-9-1 maximum frame size
increase covered above.

MQTT

• The default MQTT Maximum Packet Size changed from 256 MiB to 16 MiB.

  This default can be overridden by configuring mqtt.max_packet_size_authenticated.
  Note that this value must not be greater than max_message_size (which also defaults to 16 MiB).

etcd Peer Discovery

The following rabbitmq.conf settings are unsupported:

• cluster_formation.etcd.ssl_options.fail_if_no_peer_cert
• cluster_formation.etcd.ssl_options.dh
• cluster_formation.etcd.ssl_options.dhfile

Erlang/OTP Compatibility Notes

This release requires Erlang 26.2 and supports Erlang 27.x.

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

Release Artifacts

Artifacts are distributed via GitHub releases.

Community RabbitMQ image has a tag, 4.1, that is
periodically updated to the latest patch in these series.

Upgrading to 4.1.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 supports upgrades from 4.0.x and 3.13.x.

Blue/Green Deployment-style upgrades are avaialble for migrations
from RabbitMQ 3.12.x series.

New Required Feature Flags

None. The required feature flag set is the same as in 4.0.x.

Mixed version cluster compatibility

RabbitMQ 4.1.0 nodes can run alongside 4.0.x nodes. 4.1.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.1.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

This version does not require any additional post-upgrade procedures
compared to other versions.

Changes Worth Mentioning

This section can be incomplete and will be expanded as 4.1 approaches its release candidate stage.

Core Server

Enhancements

• Quorum queue log reads are now offloaded to channels (sessions, connections).

  In practical terms this means improved consumer throughput, lower interference of publishers
  on queue delivery rate to consumers, and improved CPU core utilization by each quorum queue
  (assuming there are enough cores available to the node).

  GitHub issue: #12713

• Feature flag quality of live improvements.

  Certain required feature flags will now be automatically required on node boot
  and do not have to be explicitly enabled before an upgrade.
  This does not apply to all feature flags, however.

  GitHub project: #4.

  GitHub issues: #12466, #12444,
  #12447

• properties and appliation-properties filters of AMQP Filter Expressions Version 1.0 Working Draft 09
  when consuming from a stream via AMQP 1.0. String prefix and suffix matching is also supported.

  This feature adds the ability to RabbitMQ to have multiple concurrent clients each consuming only a subset of messages while maintaining message order.
  It also reduces network traffic between RabbitMQ and clients by only dispatching those messages that the clients are actually interested in.

  GitHub issue: #12415

• Larger (up to 8192 bytes) JWT tokens now can be used by AMQP 0-9-1 clients.

  Before a client connection can negotiate a maximum frame size (frame_max), it must authenticate
  successfully. Before the authenticated phase, a special lower frame_max value
  is used.

  Clients that do override frame_max now must use values of 8192 bytes or greater.
  We recommend using the default server value of 131072: do not override the frame_max
  key in rabbitmq.conf and do not set it in the application code.

  amqplib is a popular client library that has been using
  a low frame_max default of 4096. Its users must upgrade to a compatible version
  (starting with 0.10.7) or explicitly use a higher frame_max.

  GitHub issue: #13541

• AMQP 1.0 connections that use OAuth 2.0 now can renew their JWT tokens
  This allows clients to set a new token proactively before the current one expires, ensuring uninterrupted connectivity.
  If a client does not set a new token before the existing one expires, RabbitMQ will automatically close the AMQP 1.0 connection.

  GitHub issue: #12599

• AMQP 1.0 filters now have capped complexity: filtering on more than 16 properties
  won't be possible. This is a protection mechanism recommended in the AMQP 1.0 spec.

  GitHub issue: #13196

• Support for Multiple Routing Keys in AMQP 1.0 via x-cc Message Annotation.

  AMQP 1.0 publishers now can set multiple routing keys by using the x-cc message annotation.
  This annotation allows publishers to specify a list
  of routing keys ([string...

RabbitMQ 4.0.9

RabbitMQ 4.0.9 is a maintenance release in the 4.0.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.

It is strongly recommended that you read 4.0 release notes
in detail if upgrading from a version prior to 4.0.0.

Minimum Supported Erlang Version

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

Nodes will fail to start on older Erlang releases.

Changes Worth Mentioning

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

Core Server

Enhancements

• Khepri: improved compatibility in mixed (Khepri) version clusters.

  GitHub issue: #13695

Management Plugin

Enhancements

• It is now possible to require authentication for the HTTP API reference page
  accessible at /api:

  management.require_auth_for_api_reference = true

  GitHub issue: #13715

Federation Plugin

Bug Fixes

• Federation status command and HTTP API endpoint could run into an exception.

  GitHub issue: #13711

AMQP 1.0 Erlang Client for RabbitMQ

Bug Fixes

• Concurrent queue declarations could fail with an exception.

  GitHub issue: #13732

Dependency Changes

• osiris was updated to 1.8.7
• khepri_mnesia_migration was upgraded to 0.7.2

Source Code Archives

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

RabbitMQ 4.1.0-rc.2

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

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

Highlights

Some key improvements in this release are listed below.

Quorum Queue Throughput and Parallelism Improvements

Quorum queue log reads are now offloaded to channels (sessions, connections).

In practical terms this means improved consumer throughput, lower interference of publishers
on queue delivery rate to consumers, and improved CPU core utilization by each quorum queue
(assuming there are enough cores available to the node).

Initial Support for AMQP 1.0 Filter Expressions

Support for the properties and application-properties filters of AMQP Filter Expressions Version 1.0 Working Draft 09.

As described in the AMQP 1.0 Filter Expressions blog post,
this feature enables multiple concurrent clients each consuming only a subset of messages from a stream while maintaining message order.

Feature Flags Quality of Life Improvements

Graduated (mandatory) feature flags several minors ago has proven that they could use some user experience improvements.
For example, certain required feature flags will now be enabled on node boot when all nodes in the cluster support them.

See core server changes below as well as the GitHub project dedicated to feature flags improvements
for the complete list of related changes.

Breaking Changes and Compatibility Notes

Initial AMQP 0-9-1 Maximum Frame Size

Before a client connection can negotiate a maximum frame size (frame_max), it must authenticate
successfully. Before the authenticated phase, a special lower frame_max value
is used.

With this release, the value was increased from the original 4096 bytes to 8192
to accommodate larger JWT tokens.

Clients that do override frame_max now must use values of 8192 bytes or greater.
We recommend using the default server value of 131072: do not override the frame_max
key in rabbitmq.conf and do not set it in the application code.

amqplib is a popular client library that has been using
a low frame_max default of 4096. Its users must upgrade to a compatible version
(starting with 0.10.7) or explicitly use a higher frame_max.

MQTT

• The default MQTT Maximum Packet Size changed from 256 MiB to 16 MiB.

  This default can be overridden by configuring mqtt.max_packet_size_authenticated.
  Note that this value must not be greater than max_message_size (which also defaults to 16 MiB).

etcd Peer Discovery

The following rabbitmq.conf settings are unsupported:

• cluster_formation.etcd.ssl_options.fail_if_no_peer_cert
• cluster_formation.etcd.ssl_options.dh
• cluster_formation.etcd.ssl_options.dhfile

Erlang/OTP Compatibility Notes

This release requires Erlang 26.2 and supports Erlang 27.x.

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

Release Artifacts

Artifacts for preview releases are distributed via GitHub releases:

• In main repository, rabbitmq/rabbitmq-server
• In the development builds repository, rabbitmq/server-packages

There is a 4.1.0 preview version of the community RabbitMQ image.

Upgrading to 4.1.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 supports upgrades from 4.0.x and 3.13.x.

Blue/Green Deployment-style upgrades are avaialble for migrations
from RabbitMQ 3.12.x series.

Required Feature Flags

None/TBD.

Mixed version cluster compatibility

RabbitMQ 4.1.0 nodes can run alongside 4.0.x nodes. 4.1.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.1.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

This version does not require any additional post-upgrade procedures
compared to other versions.

Changes Worth Mentioning

This section can be incomplete and will be expanded as 4.1 approaches its release candidate stage.

Core Server

Enhancements

• Quorum queue log reads are now offloaded to channels (sessions, connections).

  In practical terms this means improved consumer throughput, lower interference of publishers
  on queue delivery rate to consumers, and improved CPU core utilization by each quorum queue
  (assuming there are enough cores available to the node).

  GitHub issue: #12713

• Feature flag quality of live improvements.

  Certain required feature flags will now be automatically required on node boot
  and do not have to be explicitly enabled before an upgrade.
  This does not apply to all feature flags, however.

  GitHub project: #4.

  GitHub issues: #12466, #12444,
  #12447

• properties and appliation-properties filters of AMQP Filter Expressions Version 1.0 Working Draft 09
  when consuming from a stream via AMQP 1.0. String prefix and suffix matching is also supported.

  This feature adds the ability to RabbitMQ to have multiple concurrent clients each consuming only a subset of messages while maintaining message order.
  It also reduces network traffic between RabbitMQ and clients by only dispatching those messages that the clients are actually interested in.

  GitHub issue: #12415

• Larger (up to 8192 bytes) JWT tokens now can be used by AMQP 0-9-1 clients.

  Before a client connection can negotiate a maximum frame size (frame_max), it must authenticate
  successfully. Before the authenticated phase, a special lower frame_max value
  is used.

  Clients that do override frame_max now must use values of 8192 bytes or greater.
  We recommend using the default server value of 131072: do not override the frame_max
  key in rabbitmq.conf and do not set it in the application code.

  amqplib is a popular client library that has been using
  a low frame_max default of 4096. Its users must upgrade to a compatible version
  (starting with 0.10.7) or explicitly use a higher frame_max.

  GitHub issue: #13541

• AMQP 1.0 connections that use OAuth 2.0 now can renew their JWT tokens
  This allows clients to set a new token proactively before the current one expires, ensuring uninterrupted connectivity.
  If a client does not set a new token before the existing one expires, RabbitMQ will automatically close the AMQP 1.0 connection.

  GitHub issue: #12599

• AMQP 1.0 filters now have capped complexity: filtering on more than 16 properties
  won't be possible. This is a protection mechanism recommended in the AMQP 1.0 spec.

  GitHub issue: #13196

• Support for Multiple Routing Keys in AMQP 1.0 via x-cc Message Annotation.

  AMQP 1.0 publishers now can set multiple routing keys by using the x-cc message annotation.
  This annotation allows publishers to specify a list
  of routing keys (strings) for more flexible message distribution,
  similar to the CC header in AMQP 0.9.1.

  GitHub issue: #12559

• Support field dynamic of AMQP 1.0 source and target.

  This allows AMQP clients ...

RabbitMQ 4.0.8

RabbitMQ 4.0.8 is a maintenance release in the 4.0.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.

It is strongly recommended that you read 4.0 release notes
in detail if upgrading from a version prior to 4.0.0.

Minimum Supported Erlang Version

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

Nodes will fail to start on older Erlang releases.

Changes Worth Mentioning

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

Core Broker

Bug Fixes

• Fixes a number of rare replication safety issues for quorum queues and Khepri.

  GitHub issue: #13530

• Peer discovery retry limit supports the value of infinity
  but the cluster_formation.discovery_retry_limit key in rabbitmq.conf only accepted positive integers.

  Contributed by @SimonUnge.

  GitHub issue: #13676

Enhancements

• Quorum queue checkpoint algorithm was tweaked to take checkpoints more frequently, thus
  clearing older segment files more aggressively.

  Workloads that use larger messages should continue following the documented recommendations to
  avoid large disk space footprint of segment files.

  GitHub issue: #13622

• Previously a node that was a cluster member but then was reset could not
  rejoin the cluster if the schema data store was Mnesia.

  Now the reset node will try to leave the cluster and retry rejoining again.
  This was already the case for Khepri.

  Contributed by @SimonUnge.

  GitHub issue: #13669

CLI Tools

Enhancements

• rabbitmqadmin 2.0.0 GA is now available as a standalone binary.

  Learn more: rabbitmq/rabbitmqadmin-ng

• New health check commands help detect quorum queues without an elected leader.

  # Verifies that all quorum queues in virtual host "vh-1" match the naming pattern "^naming-pattern"
  # have an elected leader
  rabbitmq-diagnostics check_for_quorum_queues_without_an_elected_leader --vhost "vh-1" "^naming-pattern"
  
  # Verifies that all quorum queues in the cluster have an elected leader. This can be an expensive
  # operation if there are many quorum queues in the cluster, consider providing a more specific pattern
  rabbitmq-diagnostics check_for_quorum_queues_without_an_elected_leader --across-all-vhosts ".*"

  Contributed by @Ayanda-D.

  GitHub issue: #13489

Stream Plugin

Bug Fixes

• When a connection of one or more consumers in a Single Active Consumer group failed,
  the group could try to activate (promote) one of the consumers are are no longer online. In practical terms
  this means that other consumers were not getting any deliveries.

  GitHub issue: #13660

• TCP load balancer health checks (TCP connections that do not proceed to complete the RabbitMQ Stream Protocol handshake)
  previously resulted in an exception in the log.

  GitHub issue: #13678

Enhancements

• Stream replication connections now can be configured to use IPv6 using advanced.config:

  [
    {osiris, [
       {replica_ip_address_family, inet6}
    ]}
  ].

Management Plugin

Bug Fixes

• If HTTP API was configured to use a custom prefix, OAuth 2-based authentication would fail
  because one of the cookies used by the workflow was using an absolute path.

  GitHub issue: #13668

• Several endpoints could produce an exception when the requested resource (queue or exchange) did not exist.

  GitHub issue: #13619

• When OAuth 2 was enabled with an IDP-initiated login,
  the UI displayed a confusing warning.

  GitHub issue: #13507

Enhancements

• Historically, HTTP API access was controlled by exactly the same authentication and authorization backend chain
  that were configured for the messaging protocol connections.

  Now it is possible to use a separate chain, that is, a separate set of backends, specifically for the HTTP API access:

  # Messaging protocol access
  auth_backends.1 = ldap
  auth_backends.2 = internal
  
  # HTTP API access
  http_dispatch.auth_backends.1 = http

  Contributed by @aaron-seo.

  GitHub issue: #13467

• A new rabbitmq.conf setting, management.delegate_count, controls the size of the pool of processes
  that aggregate data to respond to HTTP API client requests.

  The default value is 5. Nodes that have access to a double digit numbers of CPU cores (say, 32)
  could benefit from using a higher number, e.g. 10 or 16.

  Contributed by @Ayanda-D.

  GitHub issue: #13462

Shovel Plugin

Bug Fixes

• AMQP 1.0 shovels could stop consuming after 2^16 - 1 messages.

  GitHub issue: #13578

LDAP Plugin

Enhancements

• The in_group_nested query now uses case-insensitive matching, which is more typical of the LDAP tooling.

  GitHub issue: #13633

Dependency Changes

• ra was upgraded to 2.15.3
• osiris was updated to 1.8.6
• credentials_obfuscation was upgraded to 3.5.0

Source Code Archives

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

RabbitMQ 4.1.0-rc.1

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

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

Highlights

Some key improvements in this release are listed below.

Quorum Queue Throughput and Parallelism Improvements

Quorum queue log reads are now offloaded to channels (sessions, connections).

In practical terms this means improved consumer throughput, lower interference of publishers
on queue delivery rate to consumers, and improved CPU core utilization by each quorum queue
(assuming there are enough cores available to the node).

Initial Support for AMQP 1.0 Filter Expressions

Support for the properties and appliation-properties filters of AMQP Filter Expressions Version 1.0 Working Draft 09.

Feature Flags Quality of Life Improvements

Graduated (mandatory) feature flags several minors ago has proven that they could use some user experience improvements.
For example, certain required feature flags will now be enabled on node boot when all nodes in the cluster support them.

See core server changes below as well as the GitHub project dedicated to feature flags improvements
for the complete list of related changes.

Breaking Changes and Compatibility Notes

Initial AMQP 0-9-1 Maximum Frame Size

Before a client connection can negotiate a maximum frame size (frame_max), it must authenticate
successfully. Before the authenticated phase, a special lower frame_max value
is used.

With this release, the value was increased from the original 4096 bytes to 8192
to accommodate larger JWT tokens.

Clients that do override frame_max now must use values of 8192 bytes or greater.
We recommend using the default server value of 131072: do not override the frame_max
key in rabbitmq.conf and do not set it in the application code.

amqplib is a popular client library that has been using
a low frame_max default of 4096. Its users must upgrade to a compatible version
(starting with 0.10.7) or explicitly use a higher frame_max.

MQTT

• The default MQTT Maximum Packet Size changed from 256 MiB to 16 MiB.

  This default can be overridden by configuring mqtt.max_packet_size_authenticated.
  Note that this value must not be greater than max_message_size (which also defaults to 16 MiB).

etcd Peer Discovery

The following rabbitmq.conf settings are unsupported:

• cluster_formation.etcd.ssl_options.fail_if_no_peer_cert
• cluster_formation.etcd.ssl_options.dh
• cluster_formation.etcd.ssl_options.dhfile

Erlang/OTP Compatibility Notes

This release requires Erlang 26.2 and supports Erlang 27.x.

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

Release Artifacts

Artifacts for preview releases are distributed via GitHub releases:

• In main repository, rabbitmq/rabbitmq-server
• In the development builds repository, rabbitmq/server-packages

There is a 4.1.0 preview version of the community RabbitMQ image.

Upgrading to 4.1.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 supports upgrades from 4.0.x and 3.13.x.

Blue/Green Deployment-style upgrades are avaialble for migrations
from RabbitMQ 3.12.x series.

Required Feature Flags

None/TBD.

Mixed version cluster compatibility

RabbitMQ 4.1.0 nodes can run alongside 4.0.x nodes. 4.1.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.1.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

This version does not require any additional post-upgrade procedures
compared to other versions.

Changes Worth Mentioning

This section can be incomplete and will be expanded as 4.1 approaches its release candidate stage.

Core Server

Enhancements

• Quorum queue log reads are now offloaded to channels (sessions, connections).

  In practical terms this means improved consumer throughput, lower interference of publishers
  on queue delivery rate to consumers, and improved CPU core utilization by each quorum queue
  (assuming there are enough cores available to the node).

  GitHub issue: #12713

• Feature flag quality of live improvements.

  Certain required feature flags will now be automatically required on node boot
  and do not have to be explicitly enabled before an upgrade.
  This does not apply to all feature flags, however.

  GitHub project: #4.

  GitHub issues: #12466, #12444,
  #12447

• properties and appliation-properties filters of AMQP Filter Expressions Version 1.0 Working Draft 09
  when consuming from a stream via AMQP 1.0. String prefix and suffix matching is also supported.

  This feature adds the ability to RabbitMQ to have multiple concurrent clients each consuming only a subset of messages while maintaining message order.
  It also reduces network traffic between RabbitMQ and clients by only dispatching those messages that the clients are actually interested in.

  GitHub issue: #12415

• Larger (up to 8192 bytes) JWT tokens now can be used by AMQP 0-9-1 clients.

  Before a client connection can negotiate a maximum frame size (frame_max), it must authenticate
  successfully. Before the authenticated phase, a special lower frame_max value
  is used.

  Clients that do override frame_max now must use values of 8192 bytes or greater.
  We recommend using the default server value of 131072: do not override the frame_max
  key in rabbitmq.conf and do not set it in the application code.

  amqplib is a popular client library that has been using
  a low frame_max default of 4096. Its users must upgrade to a compatible version
  (starting with 0.10.7) or explicitly use a higher frame_max.

  GitHub issue: #13541

• AMQP 1.0 connections that use OAuth 2.0 now can renew their JWT tokens
  This allows clients to set a new token proactively before the current one expires, ensuring uninterrupted connectivity.
  If a client does not set a new token before the existing one expires, RabbitMQ will automatically close the AMQP 1.0 connection.

  GitHub issue: #12599

• AMQP 1.0 filters now have capped complexity: filtering on more than 16 properties
  won't be possible. This is a protection mechanism recommended in the AMQP 1.0 spec.

  GitHub issue: #13196

• Support for Multiple Routing Keys in AMQP 1.0 via x-cc Message Annotation.

  AMQP 1.0 publishers now can set multiple routing keys by using the x-cc message annotation.
  This annotation allows publishers to specify a list
  of routing keys (strings) for more flexible message distribution,
  similar to the CC header in AMQP 0.9.1.

  GitHub issue: #12559

• Support field dynamic of AMQP 1.0 source and target.

  This allows AMQP clients to dynamically create exclusive queues, which can be useful for RPC workloads.

  GitHub issue: #13231

• Quorum queue checkpoint algorithm was tw...

RabbitMQ 4.1.0-beta.5

RabbitMQ 4.1.0-beta.5 is a preview release (in development) of a new feature release.

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

Highlights

Some key improvements in this release are listed below.

Initial Support for AMQP 1.0 Filter Expressions

Support for the properties and appliation-properties filters of AMQP Filter Expressions Version 1.0 Working Draft 09.

Feature Flags Quality of Life Improvements

Graduated (mandatory) feature flags several minors ago has proven that they could use some user experience improvements.
For example, certain required feature flags will now be enabled on node boot when all nodes in the cluster support them.

See core server changes below as well as the GitHub project dedicated to feature flags improvements
for the complete list of related changes.

Breaking Changes and Compatibility Notes

Initial AMQP 0-9-1 Maximum Frame Size

Before a client connection can negotiate a maximum frame size (frame_max), it must authenticate
successfully. Before the authenticated phase, a special lower frame_max value
is used.

With this release, the value was increased from the original 4096 bytes to 8192
to accommodate larger JWT tokens.

Clients that do override frame_max now must use values of 8192 bytes or greater.
We recommend using the default server value of 131072: do not override the frame_max
key in rabbitmq.conf and do not set it in the application code.

MQTT

• The default MQTT Maximum Packet Size changed from 256 MiB to 16 MiB.

  This default can be overridden by configuring mqtt.max_packet_size_authenticated.
  Note that this value must not be greater than max_message_size (which also defaults to 16 MiB).

etcd Peer Discovery

The following rabbitmq.conf settings are unsupported:

• cluster_formation.etcd.ssl_options.fail_if_no_peer_cert
• cluster_formation.etcd.ssl_options.dh
• cluster_formation.etcd.ssl_options.dhfile

Erlang/OTP Compatibility Notes

This release requires Erlang 26.2 and supports Erlang 27.x.

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

Release Artifacts

Artifacts for preview releases are distributed via GitHub releases:

• In main repository, rabbitmq/rabbitmq-server
• In the development builds repository, rabbitmq/server-packages

There is a 4.1.0 preview version of the community RabbitMQ image.

Upgrading to 4.1.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 4.0.x.

Blue/Green Deployment-style upgrades are avaialble for migrations from 3.12.x and 3.13.x series
to 4.1.x.

Required Feature Flags

None/TBD.

Mixed version cluster compatibility

RabbitMQ 4.1.0 nodes can run alongside 4.0.x nodes. 4.1.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.1.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

This version does not require any additional post-upgrade procedures
compared to other versions.

Changes Worth Mentioning

This section can be incomplete and will be expanded as 4.1 approaches its release candidate stage.

Core Server

Enhancements

• Feature flag quality of live improvements.

  Certain required feature flags will now be automatically required on node boot
  and do not have to be explicitly enabled before an upgrade.
  This does not apply to all feature flags, however.

  GitHub project: #4.

  GitHub issues: #12466, #12444,
  #12447

• properties and appliation-properties filters of AMQP Filter Expressions Version 1.0 Working Draft 09
  when consuming from a stream via AMQP 1.0. String prefix and suffix matching is also supported.

  This feature adds the ability to RabbitMQ to have multiple concurrent clients each consuming only a subset of messages while maintaining message order.
  It also reduces network traffic between RabbitMQ and clients by only dispatching those messages that the clients are actually interested in.

  GitHub issue: #12415

• AMQP 1.0 connections that use OAuth 2.0 now can renew their JWT tokens
  This allows clients to set a new token proactively before the current one expires, ensuring uninterrupted connectivity.
  If a client does not set a new token before the existing one expires, RabbitMQ will automatically close the AMQP 1.0 connection.

  GitHub issue: #12599

• AMQP 1.0 filters now have capped complexity: filtering on more than 16 properties
  won't be possible. This is a protection mechanism recommended in the AMQP 1.0 spec.

  GitHub issue: #13196

• Support for Multiple Routing Keys in AMQP 1.0 via x-cc Message Annotation.

  AMQP 1.0 publishers now can set multiple routing keys by using the x-cc message annotation.
  This annotation allows publishers to specify a list
  of routing keys (strings) for more flexible message distribution,
  similar to the CC header in AMQP 0.9.1.

  GitHub issue: #12559

• Support field dynamic of AMQP 1.0 source and target.

  This allows AMQP clients to dynamically create exclusive queues, which can be useful for RPC workloads.

  GitHub issue: #13231

• Nodes will now fall back to system CA certificate list (if available) when no CA certificate
  is explicitly configured.

  Contributed by @LoisSotoLopez.

  GitHub issue: #10519, #12564

• AMQP 1.0 and AMQP 0-9-1 connections now dynamically adjust their TCP socket buffers.

  GitHub issue: #13363

• Peer discovery resilience improvements.

  GitHub issues: #12801, #12809

• AMQP 1.0 and AMQP 0-9-1 connections now produce more specific error messages when an incorrect data is sent
  by the client during connection negotiation.

  For example, when a TLS-enabled client connects to a non-TLS port, or an HTTP GET request is sent to the AMQP port.

  GitHub issue: #13559

• AMQP 0-9-1 and AMQP 1.0 connections now use a higher pre-authentication maximum allowed frame limit size by default.
  This means that larger JWT tokens can be accepted without any configuration.

  GitHub issue: #13542

• Plugins now can mark queues and streams as protected from deletion by applications.

  GitHub issue: #13525

• Internal API changes needed by a future version of the message deduplication plugin.

  Contributed by @noxdafox.

  GitHub issue: #13374

Bug Fixes

• AMQP 0-9-1 channel exception generator could not handle entity names (say, queue or stream names)
  that contained non-ASCII characters.

  This affected applications that use passive...

RabbitMQ 4.0.7

RabbitMQ 4.0.7 is a maintenance release in the 4.0.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.

It is strongly recommended that you read 4.0 release notes
in detail if upgrading from a version prior to 4.0.0.

Minimum Supported Erlang Version

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

Nodes will fail to start on older Erlang releases.

Changes Worth Mentioning

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

Core Broker

Bug Fixes

• Classic queue message store did not remove segment files with large messages (over 4 MB) in some cases.

  GitHub issue: #13430

• A node with Khepri enabled would fail to start if its metadata store contained an exclusive queue
  with at least one binding.

  GitHub issues: #13352, #13394

Enhancements

• Reduced memory usage and GC pressure for workloads where large (4 MB or greater) messages were published to classic queues.

  Contributed by @gomoripeti.

  GitHub issue: #13375

CLI Tools

Deprecations

• rabbitmq-streams set_stream_retention_policy is now a no-op.

  It was a leftover from the early days of streams. The modern and optimal way of configuring
  stream retention is via a policy.

  GitHub issue: #13358

Prometheus Plugin

Enhancements

• New labels make it possible to differentiate between the metrics with the same name scraped from the aggregated
  metric endpoint and the per-object metric endpoint.

  GitHub issue: #13239

Management Plugin

Bug Fixes

• Two help tooltips were not updated for 4.0.x.

  GitHub issue: #13357

Enhancements

• Consumer count is a new column that can be enabled for the channels table on the tab of the same name.

  Contributed by @gomoripeti.

  GitHub issue: #13258

Caching Authentication and Authorization Backend Plugin

Enhancements

• rabbitmqctl clear_auth_backend_cache is a new command that clears the cache maintained by the plugin.

Dependency Changes

• ra was upgraded to 2.15.2

Source Code Archives

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

RabbitMQ 4.0.6

RabbitMQ 4.0.6 is a maintenance release in the 4.0.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.

It is strongly recommended that you read 4.0 release notes
in detail if upgrading from a version prior to 4.0.0.

Minimum Supported Erlang Version

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

Nodes will fail to start on older Erlang releases.

Changes Worth Mentioning

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

Core Broker

Bug Fixes

• When a quorum queue leader has changed, followers were not always notified of
  unapplied [for/by them] log commands.

  GitHub issue: #13095

• Default cluster formation timeout with Khepri now matches that of Mnesia (5 minutes by default).

  Discovered and reported by @evolvedlight.

  GitHub issue: #13195

• When stream consumer was cancelled, an internal event was not emitted.

  GitHub issues: #13085, #9356, #13097

• Stream consumer metrics were not cleared when its respective connection was closed.

  GitHub issue: #13086

• Quorum queues could return a list of members (replicas) with duplicates in some cases.

  GitHub issue: #13168

• Classic queues with priorities could run into an exception.

  GitHub issue: #13088

• Corrected a log message.

  GitHub issue: #13155

Enhancements

• A new mechanism for protecting a virtual host from deletion using metadata.

  GitHub issues: #12772, #13017

CLI Tools

Bug Fixes

• rabbitmqctl import_definitions hanged when definitions were provided via the standard input
  instead of a file.

  GitHub issue: #13157

Enhancements

• rabbitmqadmin v2 has matured enough to recommend
  it over the original version of the tool

• rabbitmq-diagnostics CLI documentation was improved to clarify that all certificates
  discovered will be checked for expiration.

  GitHub issue: #13038

• New health checks for metadata store initialization:

  1. rabbitmq-diagnostics check_if_metadata_store_is_initialized
  2. rabbitmq-diagnostics check_if_metadata_store_is_initialized_with_data

  GitHub issue: #13169

Prometheus Plugin

Bug Fixes

• Improved metric description.

  GitHub issue: #13178

Management Plugin

Bug Fixes

• Pagination-related sections of the HTTP API reference were clarified to explain
  that the maximum page size cannot exceed 500.

  GitHub issue: #13042

• Empty channel_details objects are now serialized as empty objects and not empty arrays.

  GitHub issue: #13091

Enhancements

• New health checks for metadata store initialization:

  1. GET /api/health/checks/metadata-store/initialized
  2. GET /api/health/checks/metadata-store/initialized/with-data

  GitHub issue: #13169

Deprecations

• The original HTTP API One True Health Check™ is now a no-op. A comparable "mega health check"
  has long been deprecated in CLI tools and was made a no-op in 4.0.0.

  This endpoint was using a deprecated feature: a classic non-exclusive transient (non-durable) queue.

  See Health Checks for modern focused alternatives.

  GitHub issue: #13047

Consul Peer Discovery Plugin

Enhancements

• cluster_formation.registration.enabled is a new configuration setting that allows the backend to skip registration.

  This is useful when Consul is used for peer discovery but a different tool such as Nomad
  is used to keep track of the services and their registration, unregistration.

  Contributed by @frederikbosch.

  GitHub issue: #13201

Erlang AMQP 1.0 Client

Bug Fixes

• Purging an non-existing queue now returns a 404 response.

  GitHub issue: #13148

Dependency Changes

• ra was upgraded to 2.15.1
• observer_cli was upgraded to 1.8.2

Source Code Archives

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

RabbitMQ 4.1.0-beta.4

RabbitMQ 4.1.0-beta.4 is a preview release (in development) of a new feature release.

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

Highlights

Some key improvements in this release are listed below.

Initial Support for AMQP 1.0 Filter Expressions

Support for the properties and appliation-properties filters of AMQP Filter Expressions Version 1.0 Working Draft 09.

Feature Flags Quality of Life Improvements

Graduated (mandatory) feature flags several minors ago has proven that they could use some user experience improvements.
For example, certain required feature flags will now be enabled on node boot when all nodes in the cluster support them.

See core server changes below as well as the GitHub project dedicated to feature flags improvements
for the complete list of related changes.

Breaking Changes and Compatibility Notes

MQTT

• The default MQTT Maximum Packet Size changed from 256 MiB to 16 MiB.

  This default can be overridden by configuring mqtt.max_packet_size_authenticated.
  Note that this value must not be greater than max_message_size (which also defaults to 16 MiB).

etcd Peer Discovery

The following rabbitmq.conf settings are unsupported:

• cluster_formation.etcd.ssl_options.fail_if_no_peer_cert
• cluster_formation.etcd.ssl_options.dh
• cluster_formation.etcd.ssl_options.dhfile

Erlang/OTP Compatibility Notes

This release requires Erlang 26.2 and supports Erlang 27.x.

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

Release Artifacts

Artifacts for preview releases are distributed via GitHub releases:

• In main repository, rabbitmq/rabbitmq-server
• In the development builds repository, rabbitmq/server-packages

There is a 4.1.0 preview version of the community RabbitMQ image.

Upgrading to 4.1.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 4.0.x.

Blue/Green Deployment-style upgrades are avaialble for migrations from 3.12.x and 3.13.x series
to 4.1.x.

Required Feature Flags

None/TBD.

Mixed version cluster compatibility

RabbitMQ 4.1.0 nodes can run alongside 4.0.x nodes. 4.1.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.1.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

This version does not require any additional post-upgrade procedures
compared to other versions.

Changes Worth Mentioning

This section can be incomplete and will be expanded as 4.1 approaches its release candidate stage.

Core Server

Enhancements

• Feature flag quality of live improvements.

  Certain required feature flags will now be automatically required on node boot
  and do not have to be explicitly enabled before an upgrade.
  This does not apply to all feature flags, however.

  GitHub project: #4.

  GitHub issues: #12466, #12444,
  #12447

• properties and appliation-properties filters of AMQP Filter Expressions Version 1.0 Working Draft 09
  when consuming from a stream via AMQP 1.0. String prefix and suffix matching is also supported.

  This feature adds the ability to RabbitMQ to have multiple concurrent clients each consuming only a subset of messages while maintaining message order.
  It also reduces network traffic between RabbitMQ and clients by only dispatching those messages that the clients are actually interested in.

  GitHub issue: #12415

• AMQP 1.0 connections that use OAuth 2.0 now can renew their JWT tokens
  This allows clients to set a new token proactively before the current one expires, ensuring uninterrupted connectivity.
  If a client does not set a new token before the existing one expires, RabbitMQ will automatically close the AMQP 1.0 connection.

  GitHub issue: #12599

• Nodes will now fall back to system CA certificate list (if available) when no CA certificate
  is explicitly configured.

  Contributed by @LoisSotoLopez.

  GitHub issue: #10519, #12564

• AMQP 1.0 filters now have capped complexity: filtering on more than 16 properties
  won't be possible. This is a protection mechanism recommended in the AMQP 1.0 spec.

  GitHub issue: #13196

• Support for Multiple Routing Keys in AMQP 1.0 via x-cc Message Annotation.

  AMQP 1.0 publishers now can set multiple routing keys by using the x-cc message annotation.
  This annotation allows publishers to specify a list
  of routing keys (strings) for more flexible message distribution,
  similar to the CC header in AMQP 0.9.1.

  GitHub issue: #12559

• Peer discovery resilience improvements.

  GitHub issues: #12801, #12809

Bug Fixes

• AMQP 0-9-1 channel exception generator could not handle entity names (say, queue or stream names)
  that contained non-ASCII characters.

  This affected applications that use passive queue declarations, such as the Shovel plugin.

  Contributed by @bpint.

  GitHub issue: #12888

• Reintroduced transient flow control between classic queue replicas and AMQP 0-9-1 channels,
  MQTT connections.

  Flow control between these specific parts of the core were unintentionally
  removed in 4.0.0 together with classic queue mirroring.

  Contributed by @gomoripeti.

  GitHub issue: #12907

• AMQP 1.0 connections with a higher consumption rate could set the incoming window field
  on the flow frame to a negative value, which resulted in an exception that affected the consumer.

  GitHub issues: #12816

• In rare cases quorum queue could end up without an elected leader because
  chosen candidate replica was not verified for aliveness.

  Contributed by @Ayanda-D.

  GitHub issues: #12727, #10423, #12701

• When a new replica is added to a quorum queue, the node that handles this request will now wait
  the operation to complete. Previously an early return could result in confusing cluster_change_not_permitted
  errors for subsequent operations, for example, an addition of another replica.

  GitHub issue: #12837

• In a mixed version 4.0/3.13 cluster, dead lettering a message could fail.

  GitHub issue: #12933

• In very rare cases, RabbitMQ could fail to notify stream consumers connected to follower replicas
  about newly committed offsets as quickly as it usually happens for consumers connected to the stream leader.

  GitHub issue: #12785

Bug Fixes

• Default cluster formation timeout with Khepri now matches that of Mnesia (5 minutes by default).

  Discovered and reported by @evolvedlight.

  GitHub issue: #13195

• Quorum queues could return a list of members (replicas) with duplicates in some cases.

  GitHub issue: [#13168](https://...