Releases · rabbitmq/rabbitmq-server

20 Jul 06:25

v3.13.5

edb967c

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.

Contributors

SimonUnge and luos

Assets 28

0 Join discussion

16 Jul 20:40

rabbitmq-ci

v4.0.0-beta.1

256fd8e

RabbitMQ 4.0.0-beta.1 Pre-release

Pre-release

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

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.

Assets 28

0 Join discussion

03 Jul 08:07

rabbitmq-ci

v3.13.4

ed42cd1

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.

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

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.

Contributors

SimonUnge, gomoripeti, and VlkrS

Assets 28

0 Join discussion

31 May 20:15

rabbitmq-ci

v3.13.3

61b0c55

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.

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.

Contributors

carlhoerberg, SimonUnge, and 4 other contributors

Assets 28

0 Join discussion

05 May 11:06

rabbitmq-ci

v3.12.14

42fc804

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.

Contributors

SimonUnge, illotum, and ackepenek

Assets 32

30 Apr 23:24

rabbitmq-ci

v3.13.2

dc25ef5

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.

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.

Contributors

giner, LoisSotoLopez, and aaron-seo

Assets 28

0 Join discussion

29 Mar 07:42

rabbitmq-ci

v3.13.1

06ac695

RabbitMQ 3.13.1

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

Changes Worth Mentioning

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

Core Broker

Bug Fixes

Classic queue v2 message store compaction could fail behind under high enough load,
significantly increasing node's disk space footprint.

GitHub issues: #10696, #10681
Improved quorum queue safety in mixed version clusters.

GitHub issue: #10664
When Khepri was enabled and virtual host recovery failed, subsequent recovery
attempts also failed.

GitHub issue: #10742
Messages published without any headers set on them did not have a header property
set on them. This change compared to 3.12.x was not intentional.

GitHub issues: #10623, #10620
Free disk space monitor on Windows ran into an exception if external call
to win32sysinfo.exe timed out.

GitHub issue: #10597

Enhancements

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 opened 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 (AWS).

GitHub issue: #10754

Stream Plugin

Bug Fixes

Avoids a Windows-specific stream log corruption that affected some deployments.

GitHub issue: #10822
When a super stream cannot be created because of a duplicate partition name,
a more informative error message is now used.

GitHub issue: #10535

CLI Tools

Bug Fixes

rabbitmq-plugins list --formatter=json --silent will no longer emit any warnings
when some of the plugins in the enabled plugins file are missing.

Contributed by @Ayanda-D.

GitHub issue: #10870

OAuth 2 Plugin

Bug Fixes

Configuring a JWKS URL without specifying a CA certificate resulted
in an exception with Erlang 26's TLS implementation.

GitHub issue: #8547

Management Plugin

Bug Fixes

Set default sort query parameter value for better compatibility with an external
Prometheus scraper. Note that the built-in Prometheus plugin
is the recommended way of monitoring RabbitMQ using Prometheus-compatible tools.

GitHub issue: #10610
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

Enhancements

GET /api/queues/{vhost}/{name} now supports enable_queue_totals as well as disable_stats.
This combination of query parameters can be used to retrieve message counters while
greatly reducing the number of metrics returned by the endpoints.

Contributed by @aaron-seo (AWS).

GitHub issue: #10839

Federation Plugin

Enhancements

Exchange federation now can be configured to use a custom queue type for their internal buffers.

To use a quorum queue, set the queue-type federation policy key to quorum.

GitHub issues: #4683, #10663
rabbitmq_federation_running_link_count is a new metric provided via Prometheus.

GitHub issue: #10345

Dependency Changes

osiris was updated to 1.8.1
khepri was upgraded to 0.13.0
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.13.1.tar.xz
instead of the source tarball produced by GitHub.

Contributors

illotum, ackepenek, and 2 other contributors

Assets 28

0 Join discussion

22 Feb 18:31

rabbitmq-ci

v3.13.0

c73bcd3

RabbitMQ 3.13.0

RabbitMQ 3.13.0 is a new feature 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

This release includes several new features, optimizations, internal changes in preparation for RabbitMQ 4.x,
and a major update to the RabbitMQ website.

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, providing predictable Raft-based network split and node failure recovery
MQTTv5 support
Support for consumer-side stream filtering
A new common message container format used internally, based on the AMQP 1.0 message format
Improved classic non-mirrored queue performance with message sizes larger than
4 KiB (or a different customized CQ index embedding threshold)
Classic queues storage implementation version 2 (CQv2) is now highly recommended for all new deployments.
CQv2 meaningfully improves performance of non-mirrored classic queues for most workloads

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

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 GitHub releases
for release notes of individual releases.

Note that since 3.12.0 requires all feature flags to be enabled before upgrading,
there is no upgrade path 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.x. Nodes will fail to start
on older Erlang releases.

Client Library Compatibility

Client libraries that were compatible with RabbitMQ 3.11.x and 3.12.x will be compatible with 3.13.0.
RabbitMQ Stream Protocol clients must be upgraded to their latest versions in order to support
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:

It declares a queue Q
It binds Q to an exchange X
It publishes a message M to the exchange X
It expects the message to be routed to queue Q
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:

It declares a queue Q
It binds Q to an exchange X
It gets a queue declaration confirmation back
It notifies client 2 or client 2 implicitly finds out that it has finished the steps above (for example, in an integration test)
Client Two publishes a message M to X
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.

TLS Defaults

Starting with Erlang 26, client side TLS peer certificate chain verification settings are enabled by default in most contexts:
from federation links to shovels to TLS-enabled LDAP client connections.

If using TLS peer certificate chain verification is not practical or necessary, it can be disabled.
Please refer to the docs of the feature in question, for example,
this one on TLS-enabled LDAP client connections.

Management Plugin and HTTP API

GET /api/queues` HTTP API endpoint has dropped several rarely used metrics, resulting in up to 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 a 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](https://download.opensu...

Contributors

SimonUnge, luos, and 3 other contributors

Assets 28

3 Join discussion

16 Feb 05:15

rabbitmq-ci

v3.12.13

4cbeab8

RabbitMQ 3.12.13

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

When a channel is closed, its consumer metric samples will now be cleared differently
depending on the number of them. In #9356, it was over optimized for the uncommon case with
a very large number of consumers per channel, hurting the baseline case with one or a few consumers
per channel.

In part contributed by @SimonUnge (AWS).

GitHub issue: #10478

CLI Tools

Enhancement

CLI tool startup time was reduced.

GitHub issue: #10461

Bug Fixes

JSON output formatter now avoids ANSI escape sequences.

Contributed by @ariel-anieli.

GitHub issue: #8557
ANSI escape sequences are no longer used on Windows.

Contributed by @ariel-anieli.

GitHub issue: #2634

Stream Plugin

Bug Fixes

If a stream publisher cannot be set up, a clearer message will be logged.

GitHub issue: #10524

Management Plugin

Bug Fixes

GET /api/nodes/{name} failed with a 500 when called with a non-existed node name.

GitHub issue: #10330

Shovel Plugin

Bug Fixes

AMQP 1.0 Shovels will no longer set a delivery mode header that is not meaningful in AMQP 1.0.

Contributed by @luos (Erlang Solutions).

GitHub issue: #10503

Federation Plugin

Bug Fixes

Upstream node shutdown could produce a scary looking exception in the log.

GitHub issue: #10473
Exchange federation links could run into an exception.

Contributed by @gomoripeti (CloudAMQP).

GitHub issue: #10305

Dependency Changes

cowboy was updated to 2.11.0

Source Code Archives

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

Contributors

SimonUnge, luos, and 2 other contributors

Assets 32

0 Join discussion

15 Feb 04:21

rabbitmq-ci

v3.13.0-rc.5

c14bf13

RabbitMQ 3.13.0-rc.5 Pre-release

Pre-release

RabbitMQ 3.13.0-rc.5

RabbitMQ 3.13.0-rc.5 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 server-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

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

Consider two scenarios, A and B.

Scenario A

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

It declares a queue Q
It binds Q to an exchange X
It publishes a message M to the exchange X
It expects the message to be routed to queue Q
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:

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

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

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.

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

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](https://rabbitmq.com/streams.ht...

Contributors

SimonUnge, luos, and 3 other contributors

Assets 28

0 Join discussion

Releases: rabbitmq/rabbitmq-server

RabbitMQ 3.13.5

Minimum Supported Erlang Version

Changes Worth Mentioning

Core Broker

Bug Fixes

CLI Tools

Bug Fixes

MQTT Plugin

Bug Fixes

Shovel Plugin

Enhancements

etcd Peer Discovery Plugin

Bug Fixes

Consul Peer Discovery Plugin

Bug Fixes

AWS Peer Discovery Plugin

Enhancements

Dependency Changes

Source Code Archives

Contributors

RabbitMQ 4.0.0-beta.1

Highlights

Release Artifacts

Erlang/OTP Compatibility Notes

Upgrading to 4.0

Documentation guides on upgrades

Required Feature Flags

Mixed version cluster compatibility

Recommended Post-upgrade Procedures

Changes Worth Mentioning

Dependency Changes

Source Code Archives

RabbitMQ 3.13.4

Minimum Supported Erlang Version

Changes Worth Mentioning

Core Broker

Bug Fixes

Enhancements

CLI Tools

Bug Fixes

Enhancements

OAuth 2 Plugin

Enhancements

Management Plugin

Bug Fixes

Enhancements

HTTP AuthN/AuthZ Backend Plugin

Enhancements

etcd Peer Discovery Plugin

Bug Fixes

Tracing Plugin

Enhancements

Dependency Changes

Source Code Archives

Contributors

RabbitMQ 3.13.3

Minimum Supported Erlang Version

Changes Worth Mentioning

Core Broker

Bug Fixes

Enhancements

CLI Tools

Bug Fixes

Prometheus Plugin

Enhancements

Management Plugin

Bug Fixes

Shovel Management Plugin

Bug Fixes

Dependency Changes

Source Code Archives

Contributors

RabbitMQ 3.12.14

Minimum Supported Erlang Version

Changes Worth Mentioning

Core Broker

Bug Fixes

Enhancements

AMQP 1.0 Plugin