RabbitMQ 3.9.0-rc.1

RabbitMQ 3.9.0-rc.1 is a candidate of a minor (feature) release. It contains new features, support for Erlang 24, improved integration with our RabbitMQ Kubernetes Operator, and important internal changes in a number of subsystems.

Highlights

Streams

Streams are a new persistent and replicated data structure ("queue type") in RabbitMQ which models an append-only log with non-destructive consumer semantics.

They can be used as a regular AMQP 0.9.1 queue or through a new binary protocol plugin and associated client(s).

Streams enable messaging patterns that were not possible or practical before, for example, repeatable non-destructive consumption and mass fanouts to a very large number of consumers.

Erlang 24 Support

Erlang 24 provides 20%-50% higher throughput for many workloads tested by the RabbitMQ core team and community members.

Erlang 24 is now used by default in the RabbitMQ community Docker image.

Supporting the latest runtime version also allowed RabbitMQ to replace a few external dependencies with libraries now provided by the runtime.

Kubernetes

RabbitMQ Cluster Operator automates provisioning, management, and operations of RabbitMQ clusters running on Kubernetes. It is open source and is developed by the RabbitMQ Core team at VMware, Inc.

This Operator is not specific to 3.9 and can be used with latest 3.8.x release series.

Messaging Topology Operator makes it possible to define RabbitMQ resources (virtual hosts, users, permissions, topologies, policies, etc) as Kubernetes objects. This Operator is also open source and can be used with latest 3.8.x release series.

Logging in JSON

Switch from Lager to the new Erlang Logger API for logging #2861 introduces an option for structured logging in JSON.

Obtaining Packages

RabbitMQ releases are distributed via GitHub, Cloudsmith, and PackageCloud.

Erlang/OTP Compatibility Notes

This release requires Erlang 23.2 or later. Erlang 24 is recommended as it offers 20%-50% throughput improvements for many workloads.

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

Upgrading to 3.9

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

RabbitMQ 3.9.0 nodes can run alongside 3.8.x nodes. However, 3.8.16+ as well as 3.9.x both require Erlang 23.2 or later (and support 24). 3.9.x-specific features can only be made available when all nodes in the cluster upgrade to 3.9.0 (or a later 3.9.x release).

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.9.0, these irregularities will go away.

Mixed version clusters are a mechanism that allows rolling upgrade and are not meant to be run for longer periods of time.

Quorum Queue Declaration

In a mixed version cluster, declaration of new quorum queues will fail if executed on a node in the version minority. For example, in a five node cluster with two nodes running 3.8, the three 3.9 nodes are in the version majority and the remaining are in the version minority.

Existing quorum queues will operate just like before.

Classic Queue Metrics

HTTP API responses will provide a limited number of metrics or metrics for a limited number of queues (for operations such as GET /api/queues/{vhost}) when operating in mixed version mode.

Compatibility Notes

Client Library Compatibility

Client libraries that were compatible with RabbitMQ 3.8.x will be compatible with 3.9.0.

Upgrading to Erlang 24.x

RabbitMQ 3.8.16 and later require Erlang 23.2 and support Erlang 24. 24 is recommended. Users of versions that do not support Erlang 23.2 should first upgrade to the latest 3.8.x patch release pn Erlang 23.2, then upgrade to 3.9.0 on Erlang 24.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome on the RabbitMQ mailing list.

Changes Worth Mentioning

Core Server

Enhancements

• Streams, a new durable replicated data structure that allows for repeatable (non-destructive) consumption. RabbitMQ 3.9 introduces a new binary protocol for working with streams. While streams can be used by AMQP 0-9-1 clients, in most cases it will be used via a RabbitMQ stream binary protocol client. The new protocol exposes all the operations specific to this queue type and is heavily optimized for them, resulting in much higher read and write throughput.

  Java and Go clients

• Structural logging in JSON. Nodes can now log in JSON format.

  GitHub issue: #2861

• Peer discovery no longer uses randomized startup delay to ensure only one node starts as a seed one during initial (parallel) cluster formation. Instead it relies on an internal runtime locking library.

  GitHub issue: #3075

• Binding recovery on node startup is now more efficient. This means in clusters with a lot of queues and/or bindings, nodes start quicker.

  GitHub issue: #3137

• Classic mirrored queue replcas are now started synchronously.

  GitHub issue: #2751

• journald notifications are now performed using a library and not an external tool (socat)

  GitHub issue: #2940

• Startup banner now provides more information some of which can be customised.

  GitHub issues: #2247, #2777

• Per-protocol and queue type message rates are now available as Prometheus metrics, as well as Streams-specific errors. This also addresses a long-standing 3.8.x counters issue for most metrics of this type, as captured in #2783.

  GitHub issues: #3127, #3136, #3157

Internal API and Other Changes

• Standard runtime logger is now used for logging instead of Lager, a 3rd party dependency. In modern Erlang versions, the module offers at least a comparable feature set and efficiency of Lager.

  Users who relied on Lager-specific configuration, e.g. custom extensions or sinks, would have to rebuild them on top of the standard Erlang logger module.

  GitHub issue: #2861

• Different Raft-based features now can have different defaults and settings, with more configurability coming at a later point. For example, client ID tracking in the MQTT plugin can use settings for lower memory footprint and more frequent compaction while stream and quorum queues use settings more optimal for higher throughput on the same node.

  GitHub issue: #2909

• Continuous integration of open source RabbitMQ has switched to Bazel, GitHub Actions and BuildBuddy, resulting in much faster and incremental test runs.

  Bazel support for Erlang is a new project open sourced by the RabbitMQ Core team as a result.

• Process group membership now uses pg.

  GitHub issue: #2850

Bug Fixes

• powershell.exe now can run without profile.

  GitHub issue: #2201

• Queue index recovery now can continue after a forced node shutdown during recovery (e.g. killed)

  GitHub issue: #3099

Kubernetes

Enhancements

• RabbitMQ Cluster Operator automates provisioning, management, and operations of RabbitMQ clusters running on Kubernetes.

• [Messaging Topology Operator]...

RabbitMQ 3.8.19

RabbitMQ 3.8.19 is a maintenance release.

Obtaining Packages

RabbitMQ releases are distributed via GitHub, Cloudsmith,
and PackageCloud.

Erlang/OTP Compatibility Notes

This release requires Erlang 23.2 and supports Erlang 24.

Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision modern Erlang versions.

Upgrade and Compatibility Notes

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

If upgrading from a3.7.x release, see 3.8.0 release notes
upgrade and compatibility notes first.

If upgrading from a 3.6.x or older release series, first upgrade
to 3.7.27 and then to this version.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome on the RabbitMQ mailing list
and RabbitMQ community Slack.

Changes Worth Mentioning

Core Server

Enhancements

• Binding recovery on node startup is now more efficient. This means in clusters with a lot of
  queues and/or bindings, nodes start quicker.

  GitHub issue: #3137

• Plugin directory paths are now deduplicated, so if a single directory is specified
  more than once, the node won't complain about duplicate plugins.

  GitHub issue: #3155

• Startup banner and log entries now use path separators more consistently on Windows.

  Thanks to Linda @LindaLawton Lawton for pointing out the inconsistency.

  GitHub issue: #3149

Shovel Plugin

Bug Fixes

• When dynamic Shovels are started the plugin now acquires a distributed lock.
  This is generally not necessary but helps avoid duplicate Shovels being started
  via import of a definition file on every cluster node during cluster formation.

  GitHub issue: #3167

Dependency Upgrades

No dependency changes in this release.

Source Code Archives

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

RabbitMQ 3.8.19-rc.1

RabbitMQ 3.8.19-rc.1 is a preview of a maintenance release.

Obtaining Packages

RabbitMQ releases are distributed via GitHub, Cloudsmith,
and PackageCloud.

Erlang/OTP Compatibility Notes

This release requires Erlang 23.2 and supports Erlang 24.

Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision modern Erlang versions.

Upgrade and Compatibility Notes

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

If upgrading from a3.7.x release, see 3.8.0 release notes
upgrade and compatibility notes first.

If upgrading from a 3.6.x or older release series, first upgrade
to 3.7.27 and then to this version.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome on the RabbitMQ mailing list
and RabbitMQ community Slack.

Changes Worth Mentioning

Core Server

Enhancements

• Binding recovery on node startup is now more efficient. This means in clusters with a lot of
  queues and/or bindings, nodes start quicker.

  GitHub issue: #3137

• Plugin directory paths are now deduplicated, so if a single directory is specified
  more than once, the node won't complain about duplicate plugins.

  GitHub issue: #3155

• Startup banner and log entries now use path separators more consistently on Windows.

  Thanks to Linda @LindaLawton Lawton for pointing out the inconsistency.

  GitHub issue: #3149

Shovel Plugin

Bug Fixes

• When dynamic Shovels are started the plugin now acquires a distributed lock.
  This is generally not necessary but helps avoid duplicate Shovels being started
  via import of a definition file on every cluster node during cluster formation.

  GitHub issue: #3167

Dependency Upgrades

No dependency changes in this release.

Source Code Archives

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

RabbitMQ 3.9.0-beta.2

RabbitMQ 3.9.0-beta.2 is a preview of a feature release. It contains new features, support for Erlang 24, a RabbitMQ Kubernetes Operator developed by the RabbitMQ Core team, and important internal changes in a number of subsystems.

It also includes all bug fixes and minor incremental improvements from the 3.8.x release series unless stated otherwise.

Highlights

Streams

Streams are a new persistent and replicated data structure ("queue type") in RabbitMQ which models an append-only log with non-destructive consumer semantics.

They can be used as a regular AMQP 0.9.1 queue or through a new binary protocol plugin and associated client(s).

Streams enable messaging patterns that were not possible or practical before, for example, repeatable non-destructive consumption and mass fanouts to a very large number of consumers.

Erlang 24 Support

Erlang 24 provides substantial throughput gains for many workloads tested by the RabbitMQ core team and community members.

Erlang 24 is now used by default in the community Docker image for RabbitMQ.

It also allowed RabbitMQ to replace a few external dependencies with libraries now provided by the runtime.

Kubernetes

RabbitMQ Cluster Operator automates provisioning, management, and operations of RabbitMQ clusters running on Kubernetes. It is open source and is developed by the RabbitMQ Core team at VMware, Inc.

This Operator is not specific to 3.9 and can be used with latest 3.8.x release series.

Messaging Topology Operator makes it possible to define RabbitMQ resources (virtual hosts, users, permissions, topologies, policies, etc) as Kubernetes objects. This Operator is also open source and can be used with latest 3.8.x release series.

Logging in JSON

Switch from Lager to the new Erlang Logger API for logging #2861 introduces an option for structured logging in JSON.

Obtaining Packages

RabbitMQ releases are distributed via GitHub, Cloudsmith, and PackageCloud.

Erlang/OTP Compatibility Notes

This release requires Erlang 23.2 or later. Erlang 24 is recommended as it offers substantial throughput improvements for many workloads.

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

Upgrading to 3.9

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

RabbitMQ 3.9.0 nodes can run alongside 3.8.x nodes. However, 3.8.16+ as well as 3.9.x both require Erlang 23.2 or later (and support 24). No 3.9.0-specific features would be available in a mixed version cluster.

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.9.0, these irregularities will go away.

Mixed version clusters are a mechanism that allows rolling upgrade and are not meant to be run for longer periods of time.

Quorum Queue Declaration

In a mixed version cluster, declaration of new quorum queues will fail if executed on a node in the version minority. For example, in a five node cluster with two nodes running 3.8, the three 3.9 nodes are in the version majority and the remaining are in the version minority.

Existing quorum queues will operate just like before.

Classic Queue Metrics

HTTP API responses will provide a limited number of metrics or metrics for a limited number of queues (for operations such as GET /api/queues/{vhost}) when operating in mixed version mode.

Compatibility Notes

Client Library Compatibility

Client libraries that were compatible with RabbitMQ 3.8.x will be compatible with 3.9.0.

Upgrading to Erlang 24.x

RabbitMQ 3.8.16 and later require Erlang 23.2 and support Erlang 24. 24 is recommended. Users of versions that do not support Erlang 23.2 should first upgrade to the latest 3.8.x patch release pn Erlang 23.2, then upgrade to 3.9.0 on Erlang 24.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome on the
RabbitMQ mailing list.

Changes Worth Mentioning

Core Server

Enhancements

• Streams, a new durable replicated data structure that allows for repeatable (non-destructive) consumption. RabbitMQ 3.9 introduces a new binary protocol for working with streams. While streams can be used by AMQP 0-9-1 clients, in most cases it will be used via a RabbitMQ stream binary protocol client. The new protocol exposes all the operations specific to this queue type and is heavily optimized for them, resulting in much higher read and write throughput.

  Java and Go clients

• Structural logging in JSON. Nodes can now log in JSON format.

  GitHub issue: #2861

• Peer discovery no longer uses randomized startup delay to ensure only one node starts as a seed one during initial (parallel) cluster formation. Instead it relies on an internal runtime locking library.

  GitHub issue: #3075

• Binding recovery on node startup is now more efficient. This means in clusters with a lot of queues and/or bindings, nodes start quicker.

  GitHub issue: #3137

• Classic mirrored queue replcas are now started synchronously.

  GitHub issue: #2751

• journald notifications are now performed using a library and not an external tool (socat)

  GitHub issue: #2940

• Startup banner now provides more information some of which can be customised.

  GitHub issues: #2247, #2777

Internal API and Other Changes

• Standard runtime logger is now used for logging instead of Lager, a 3rd party dependency. In modern Erlang versions, the module offers at least a comparable feature set and efficiency of Lager.

  Users who relied on Lager-specific configuration, e.g. custom extensions or sinks, would have to rebuild them on top of the standard Erlang logger module.

  GitHub issue: #2861

• Different Raft-based features now can have different defaults and settings, with more configurability coming at a later point. For example, client ID tracking in the MQTT plugin can use settings for lower memory footprint and more frequent compaction while stream and quorum queues use settings more optimal for higher throughput on the same node.

  GitHub issue: #2909

• Continuous integration of open source RabbitMQ has switched to Bazel, GitHub Actions and BuildBuddy, resulting in much faster and incremental test runs.

  Bazel support for Erlang is a new project open sourced by the RabbitMQ Core team as a result.

• Process group membership now uses pg.

  GitHub issue: #2850

Bug Fixes

• powershell.exe now can run without profile.

  GitHub issue: #2201

• Queue index recovery now can continue after a forced node shutdown during recovery (e.g. killed)

  GitHub issue: #3099

Kubernetes

Enhancements

• RabbitMQ Cluster Operator automates provisioning, management, and operations of RabbitMQ clusters running on Kubernetes.

• Messaging Topology Operator makes it possible to define RabbitMQ resources (virtual hosts, users, permissions, topologies, policies, etc) as Kubernetes objects.

• Kubernetes peer discovery mechanism no longer uses randomized delays to avoid the inherent race condition during [initial cluster formation](https://www.rabbitmq.com/cluster-formatio...

RabbitMQ 3.8.18

RabbitMQ 3.8.18 is a maintenance release that includes a security patch.

This release addresses an undisclosed vulnerability with CVSS 3.1 score of 3.1 (low): CVE-2021-32719.

Our team would like to thank Fahimhusain Raydurg for responsibly disclosing
the vulnerability and Patrik Ragnarsson from CloudAMQP for contributing a fix.

Obtaining Packages

RabbitMQ releases are distributed via GitHub, Cloudsmith,
and PackageCloud.

Erlang/OTP Compatibility Notes

This release requires Erlang 23.2 and supports Erlang 24.

Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision modern Erlang versions.

Upgrade and Compatibility Notes

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

If upgrading from a3.7.x release, see 3.8.0 release notes
upgrade and compatibility notes first.

If upgrading from a 3.6.x or older release series, first upgrade
to 3.7.27 and then to this version.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome on the RabbitMQ mailing list
and RabbitMQ community Slack.

Changes Worth Mentioning

Core Server

Enhancements

• Peer discovery no longer uses randomized delays to avoid the inherent race condition
  during initial cluster formation. Instead it relies on an internal
  distributed locking mechanism available in modern Erlang releases.

  While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node
  startup, it by definition assumes that with some low probability more than one node can still start as seed nodes,
  and be joined by different groups of cluster peers. The locking mechanism does not have this downside.
  Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery.
  Note that etcd and Consul-based peer discovery still use those service's support for distributed locks.

  cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys
  will no longer have any effect.

  GitHub issue: #3075

• Node startup banner now includes Erlang version, runtime operation mode (JIT vs. emulator),
  and underlying crypto library version (e.g. OpenSSL 1.1.1k) it was built against.

  GitHub issue: #2777

• Build system targets now use hostname(1) in a way that is compatible with Solaris.

  Contributed by Pavel @tropikhajma Heimlich.

  GitHub issue: #3117

Bug Fixes

• Queue deletion could run into an exception in some rare cases.

  Contributed by @tomyouyou.

  GitHub issue: #3086

Prometheus Plugin

Bug Fixes

• In certain double stack (IPv4 and IPv6) environments, the plugin would start a single listener
  but register two internally. That extra non-existent listener would make rabbitmq-diagnostics drain
  fail as it disables all registered listeners.

  GitHub issue: #3021

Management Plugin

Bug Fixes

• In certain double stack (IPv4 and IPv6) environments, the plugin would start a single listener
  but register two internally. That extra non-existent listener would make rabbitmq-diagnostics drain
  fail as it disables all registered listeners.

  GitHub issue: #3021

Kubernetes Peer Discovery Plugin

Enhancements

• Kubernetes peer discovery mechanism no longer uses randomized delays to avoid the inherent race condition
  during initial cluster formation. Instead it relies on an internal
  distributed locking mechanism available in modern Erlang releases.

  While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node
  startup, it by definitely assumes that with some low probability more than one node can still start as seed nodes,
  and be joined by different groups of cluster peers. The locking mechanism does not have this downside.
  Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery.

  cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys
  will no longer have any effect.

  GitHub issue: #3075

AWS Peer Discovery Plugin

Enhancements

• AWS peer discovery mechanism no longer uses randomized delays to avoid the inherent race condition
  during initial cluster formation. Instead it relies on an internal
  distributed locking mechanism available in modern Erlang releases.

  While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node
  startup, it by definitely assumes that with some low probability more than one node can still start as seed nodes,
  and be joined by different groups of cluster peers. The locking mechanism does not have this downside.
  Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery.

  cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys
  will no longer have any effect.

  GitHub issue: #3075

Federation Plugin

Bug Fixes

• Queue federation will now declare queues on the upstream side only if it does not already
  exist. This makes it possible to federate pre-declared queues of different types.

  Note that such setups should be considered edge cases. Queue federation was never meant
  to federated queues of different types under the same name in different clusters.
  Such setups could be useful in Blue/Green deployment upgrade scenarios but
  otherwise should be avoided.

  GitHub issue: #3107

AuthN/AuthZ Backend HTTP Plugin

Bug Fixes

• auth_http.connection_timeout and auth_http.request_timeout are two new configuration parameters that control HTTP client connection
  and overall request timeouts. They both default to 15 seconds. The value can be increased for services that can occasionally slow down
  significantly.

  Contributed by Miłosz @SzumiecM Szumiec.

  GitHub issue: #3140

Dependency Upgrades

• jose was updated from 1.11.1 to 2b1d66b5f4
• jsx was updated from 2.11.0 to 3.1.0
• observer_cli was updated from 1.6.1 to 1.6.2

Source Code Archives

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

RabbitMQ 3.9.0-beta.1

RabbitMQ 3.9.0-beta.1

RabbitMQ 3.9.0-beta.1 is a preview of a feature release. It contains new features, support for Erlang 24, a RabbitMQ Kubernetes Operator developed by the RabbitMQ Core team,
and important internal changes in a number of subsystems.

It also includes all bug fixes and minor incremental improvements from the 3.8.x release series unless stated otherwise.

Highlights

Streams

Streams are a new persistent and replicated data structure ("queue type") in RabbitMQ which models an append-only log with non-destructive consumer semantics.

They can be used as a regular AMQP 0.9.1 queue or through a new binary protocol plugin and associated client(s).

Streams enable messaging patterns that were not possible or practical before, for example, repeatable non-destructive consumption and mass fanouts to a very large number of consumers.

Erlang 24 Support

Erlang 24 provides substantial throughput gains for many workloads tested by the RabbitMQ core team and community members.

Erlang 24 is now used by default in the community Docker image for RabbitMQ.

It also allowed RabbitMQ to replace a few external dependencies with libraries now provided by the runtime.

Kubernetes

RabbitMQ Cluster Operator automates provisioning, management, and operations of RabbitMQ clusters running on Kubernetes.
It is open source and is developed by the RabbitMQ Core team at VMware, Inc.

This Operator is not specific to 3.9 and can be used with latest 3.8.x release series.

Messaging Topology Operator makes it possible to define RabbitMQ resources (virtual hosts, users, permissions, topologies, policies, etc) as Kubernetes objects.
This Operator is also open source and can be used with latest 3.8.x release series.

Logging in JSON

Switch from Lager to the new Erlang Logger API for logging #2861 introduces an option for structured logging in JSON.

Obtaining Packages

RabbitMQ releases are distributed via GitHub, Cloudsmith, and PackageCloud.

Erlang/OTP Compatibility Notes

This release requires Erlang 23.2 or later. Erlang 24 is recommended as it offers substantial throughput improvements for many workloads.

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

Upgrading to 3.9

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

RabbitMQ 3.9.0 nodes can run alongside 3.8.x nodes. However, 3.8.16+ as well as 3.9.x both require Erlang 23.2 or later (and support 24).
No 3.9.0-specific features would be available in a mixed version cluster.

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.9.0, these irregularities will go away.

Mixed version clusters are a mechanism that allows rolling upgrade and are not meant to be run for longer periods of time.

Quorum Queue Declaration

In a mixed version cluster, declaration of new quorum queues will fail if executed on a node in the version minority. For example, in a five node cluster with two nodes running 3.8, the three 3.9 nodes are in the version majority and the remaining are in the version minority.

Existing quorum queues will operate just like before.

Classic Queue Metrics

HTTP API responses will provide a limited number of metrics or metrics for a limited number of queues (for operations such as GET /api/queues/{vhost}) when operating in mixed version mode.

Compatibility Notes

Client Library Compatibility

Client libraries that were compatible with RabbitMQ 3.8.x will be compatible with 3.9.0.

Upgrading to Erlang 24.x

RabbitMQ 3.8.16 and later require Erlang 23.2 and support Erlang 24. 24 is recommended.
Users of versions that do not support Erlang 23.2 should first upgrade to the latest 3.8.x patch release pn Erlang 23.2, then upgrade to 3.9.0 on Erlang 24.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome on the RabbitMQ mailing list.

Changes Worth Mentioning

Core Server

Enhancements

• Streams, a new durable replicated data structure that allows for repeatable (non-destructive) consumption. RabbitMQ 3.9 introduces a new binary protocol for working with streams. While streams can be used by AMQP 0-9-1 clients, in most cases it will be used via a RabbitMQ stream binary protocol client. The new protocol exposes all the operations specific to this queue type and is heavily optimized for them, resulting in much higher read and write throughput.

  Java and Go clients

• Structural logging in JSON. Nodes can now log in JSON format.

  GitHub issue: #2861

• Peer discovery no longer uses randomized startup delay to ensure only one node starts
  as a seed one during initial (parallel) cluster formation. Instead it relies on an internal
  runtime locking library.

  GitHub issue: #3075

• Classic mirrored queue replcas are now started synchronously.

  GitHub issue: #2751

• journald notifications are now performed using a library and not an external tool (socat)

  GitHub issue: #2940

• Some properties of the product banner can be customized

Internal API and Other Changes

• Standard runtime logger is now used for logging instead of Lager, a 3rd party dependency. In modern Erlang versions, the module offers at least a comparable feature set and efficiency of Lager.

  Users who relied on Lager-specific configuration, e.g. custom extensions or sinks, would have to rebuild them on top of the standard Erlang logger module.

  GitHub issue: #2861

• Different Raft-based features now can have different defaults and settings, with more configurability coming at a later point. For example, client ID tracking in the MQTT plugin can use settings for lower memory footprint and more frequent compaction while stream and quorum queues use settings more optimal for higher throughput on the same node.

  GitHub issue: #2909

• Continuous integration of open source RabbitMQ has switched to Bazel, GitHub Actions and BuildBuddy, resulting in much faster and incremental test runs.

  Bazel support for Erlang is a new project open sourced by the RabbitMQ Core team as a result.

• Process group membership now uses pg.

  GitHub issue: #2850

Bug Fixes

• powershell.exe now can run without profile.

  GitHub issue: #2201

• Queue index recovery now can continue after a forced node shutdown during recovery
  (e.g. killed)

  GitHub issue: #3099

Kubernetes

Enhancements

• RabbitMQ Cluster Operator automates provisioning, management, and operations of RabbitMQ clusters running on Kubernetes.

• Messaging Topology Operator makes it possible to define RabbitMQ resources (virtual hosts, users, permissions, topologies, policies, etc) as Kubernetes objects.

• Kubernetes peer discovery mechanism no longer uses randomized delays to avoid the inherent race condition during initial cluster formation. Instead it relies on an internal distributed locking mechanism available in modern Erlang releases.

  While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node startup, it by definitely assu...

RabbitMQ 3.8.18-rc.1

RabbitMQ 3.8.18-rc.1

RabbitMQ 3.8.18-rc.1 is a maintenance release candidate.

Obtaining Packages

RabbitMQ releases are distributed via GitHub, Cloudsmith,
and PackageCloud.

Erlang/OTP Compatibility Notes

This release requires Erlang 23.2 and supports Erlang 24.

Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision modern Erlang versions.

Upgrade and Compatibility Notes

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

If upgrading from a3.7.x release, see 3.8.0 release notes
upgrade and compatibility notes first.

If upgrading from a 3.6.x or older release series, first upgrade
to 3.7.27 and then to this version.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome on the RabbitMQ mailing list
and RabbitMQ community Slack.

Changes Worth Mentioning

Core Server

Enhancements

• Peer discovery no longer uses randomized delays to avoid the inherent race condition
  during initial cluster formation. Instead it relies on an internal
  distributed locking mechanism available in modern Erlang releases.

  While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node
  startup, it by definitely assumes that with some low probability more than one node can still start as seed nodes,
  and be joined by different groups of cluster peers. The locking mechanism does not have this downside.
  Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery.
  Note that etcd and Consul-based peer discovery still use those service's support for distributed locks.

  cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys
  will no longer have any effect.

  GitHub issue: #3075

• Build system targets now use hostname(1) in a way that is compatible with Solaris.

  Contributed by Pavel @tropikhajma Heimlich.

  GitHub issue: #3117

Bug Fixes

• Queue deletion could run into an exception in some rare cases.

  Contributed by @tomyouyou.

  GitHub issue: #3086

Prometheus Plugin

Bug Fixes

• In certain double stack (IPv4 and IPv6) environments, the plugin would start a single listener
  but register two internally. That extra non-existent listener would make rabbitmq-diagnostics drain
  fail as it disables all registered listeners.

  GitHub issue: #3021

Management Plugin

Bug Fixes

• In certain double stack (IPv4 and IPv6) environments, the plugin would start a single listener
  but register two internally. That extra non-existent listener would make rabbitmq-diagnostics drain
  fail as it disables all registered listeners.

  GitHub issue: #3021

Kubernetes Peer Discovery Plugin

Enhancements

• Kubernetes peer discovery mechanism no longer uses randomized delays to avoid the inherent race condition
  during initial cluster formation. Instead it relies on an internal
  distributed locking mechanism available in modern Erlang releases.

  While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node
  startup, it by definitely assumes that with some low probability more than one node can still start as seed nodes,
  and be joined by different groups of cluster peers. The locking mechanism does not have this downside.
  Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery.

  cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys
  will no longer have any effect.

  GitHub issue: #3075

AWS Peer Discovery Plugin

Enhancements

• AWS peer discovery mechanism no longer uses randomized delays to avoid the inherent race condition
  during initial cluster formation. Instead it relies on an internal
  distributed locking mechanism available in modern Erlang releases.

  While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node
  startup, it by definitely assumes that with some low probability more than one node can still start as seed nodes,
  and be joined by different groups of cluster peers. The locking mechanism does not have this downside.
  Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery.

  cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys
  will no longer have any effect.

  GitHub issue: #3075

Federation Plugin

Bug Fixes

• Queue federation will now declare queues on the upstream side only if it does not already
  exist. This makes it possible to federate pre-declared queues of different types.

  Note that such setups should be considered edge cases. Queue federation was never meant
  to federated queues of different types under the same name in different clusters.
  Such setups could be useful in Blue/Green deployment upgrade scenarios but
  otherwise should be avoided.

  GitHub issue: #3107

Dependency Upgrades

• jose was updated from 1.11.1 to 2b1d66b5f4
• jsx was updated from 2.11.0 to 3.1.0
• observer_cli was updated from 1.6.1 to 1.6.2

Source Code Archives

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

RabbitMQ 3.8.18-beta.1

RabbitMQ 3.8.18-beta.1

RabbitMQ 3.8.18-beta.1 is a preview of a maintenance release.

Obtaining Packages

RabbitMQ releases are distributed via GitHub, Cloudsmith,
and PackageCloud.

Erlang/OTP Compatibility Notes

This release requires Erlang 23.2 and supports Erlang 24.

Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision modern Erlang versions.

Upgrade and Compatibility Notes

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

If upgrading from a3.7.x release, see 3.8.0 release notes
upgrade and compatibility notes first.

If upgrading from a 3.6.x or older release series, first upgrade
to 3.7.27 and then to this version.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome on the RabbitMQ mailing list
and RabbitMQ community Slack.

Changes Worth Mentioning

Core Server

Enhancements

• Peer discovery no longer uses randomized delays to avoid the inherent race condition
  during initial cluster formation. Instead it relies on an internal
  distributed locking mechanism available in modern Erlang releases.

  While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node
  startup, it by definitely assumes that with some low probability more than one node can still start as seed nodes,
  and be joined by different groups of cluster peers. The locking mechanism does not have this downside.
  Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery.
  Note that etcd and Consul-based peer discovery still use those service's support for distributed locks.

  cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys
  will no longer have any effect.

  GitHub issue: #3075

Bug Fixes

• Queue deletion could run into an exception in some rare cases.

  Contributed by @tomyouyou.

  GitHub issue: #3086

Kubernetes Peer Discovery Plugin

Enhancements

• Kubernetes peer discovery mechanism no longer uses randomized delays to avoid the inherent race condition
  during initial cluster formation. Instead it relies on an internal
  distributed locking mechanism available in modern Erlang releases.

  While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node
  startup, it by definitely assumes that with some low probability more than one node can still start as seed nodes,
  and be joined by different groups of cluster peers. The locking mechanism does not have this downside.
  Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery.

  cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys
  will no longer have any effect.

  GitHub issue: #3075

AWS Peer Discovery Plugin

Enhancements

• AWS peer discovery mechanism no longer uses randomized delays to avoid the inherent race condition
  during initial cluster formation. Instead it relies on an internal
  distributed locking mechanism available in modern Erlang releases.

  While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node
  startup, it by definitely assumes that with some low probability more than one node can still start as seed nodes,
  and be joined by different groups of cluster peers. The locking mechanism does not have this downside.
  Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery.

  cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys
  will no longer have any effect.

  GitHub issue: #3075

Dependency Upgrades

• jose was updated from 1.11.1 to 2b1d66b5f4
• jsx was updated from 2.11.0 to 3.1.0
• observer_cli was updated from 1.6.1 to 1.6.2

Source Code Archives

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

RabbitMQ 3.8.17

RabbitMQ 3.8.17

RabbitMQ 3.8.17 is a maintenance release that includes a security patch.

Security Patches

This release addresses an undisclosed vulnerability with CVSS 3.1 score of 3.1 (low): CVE-2021-32718.

Our team would like to thank Christian Rellmann from usd AG for responsibly disclosing
the vulnerability and helping us verify a fix.

Obtaining Packages

RabbitMQ releases are distributed via GitHub, Cloudsmith,
and PackageCloud.

Erlang/OTP Compatibility Notes

This release requires Erlang 23.2 and supports Erlang 24.

Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision modern Erlang versions.

Upgrade and Compatibility Notes

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

If upgrading from a3.7.x release, see 3.8.0 release notes
upgrade and compatibility notes first.

If upgrading from a 3.6.x or older release series, first upgrade
to 3.7.27 and then to this version.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome on the RabbitMQ mailing list
and RabbitMQ community Slack.

Changes Worth Mentioning

Core Server

Enhancements

• Queue index efficiency improvements, mostly around peak memory consumption with large backlogs of small messages.

  Note that some of the improvements come from more optimal defaults: those will only be
  applicable to newly created virtual hosts (or new clusters).

  GitHub issues: #2954, #3041

• Consumer delivery acknowledgement timeout default has been bumped to 30 minutes (previously 15 minutes). The value
  can be overridden.

  GitHub issue: #3033

Bug Fixes

• A classic queue with single active consumer option enabled could run into
  an exception after a restart or initial enablement of the management plugin.

  GitHub issue: #3072

Management Plugin

Bug Fixes

• A combination of HTTPS (TLS) settings and advanced HTTP server settings
  resulted in an exception.

  GitHub issue: #3039

• External stats collector is now restarted again if it fails for any reason.

  Contributed by @luos.

  GitHub issue: #3040

Consistent History Exchange Plugin

Enhancements

• When nodes are restarted, schema database tables used by this plugin are now reconciled
  with cluster peers the same way RabbitMQ core does it.

  GitHub issue: #3067

Recent History Exchange Plugin

Enhancements

• When nodes are restarted, schema database tables used by this plugin are now reconciled
  with cluster peers the same way RabbitMQ core does it.

  GitHub issue: #3067

Delayed Message Exchange Plugin

Enhancements

• When nodes are restarted, schema database tables used by this plugin are now reconciled
  with cluster peers the same way RabbitMQ core does it.

  Contributed by @mwfriedm.

  GitHub issue: rabbitmq/rabbitmq-delayed-message-exchange#163

Last Value Cache Exchange Plugin

Enhancements

• When nodes are restarted, schema database tables used by this plugin are now reconciled
  with cluster peers the same way RabbitMQ core does it.

  GitHub issue: rabbitmq/rabbitmq-lvc-exchange#28

Web MQTT Plugin

Bug Fixes

• MQTT-over-WebSockets client connections were not accounted for by the file handle tracking mechanism (metric and resource alarm).

  GitHub issue: #3076

Dependency Upgrades

None in this release.

Source Code Archives

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

RabbitMQ 3.8.17-rc.2

RabbitMQ 3.8.17-rc.2

RabbitMQ 3.8.17-rc.2 is a preview of a maintenance release.

Obtaining Packages

RabbitMQ releases are distributed via GitHub, Cloudsmith,
and PackageCloud.

Erlang/OTP Compatibility Notes

This release requires Erlang 23.2 and supports Erlang 24.

Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision modern Erlang versions.

Upgrade and Compatibility Notes

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

If upgrading from a3.7.x release, see 3.8.0 release notes
upgrade and compatibility notes first.

If upgrading from a 3.6.x or older release series, first upgrade
to 3.7.27 and then to this version.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome on the RabbitMQ mailing list
and RabbitMQ community Slack.

Changes Worth Mentioning

Core Server

Enhancements

• Queue index efficiency improvements, mostly around peak memory consumption with large backlogs of small messages.

  Note that some of the improvements come from more optimal defaults: those will only be
  applicable to newly created virtual hosts (or new clusters).

  GitHub issues: #2954, #3041

• Consumer delivery acknowledgement timeout default has been bumped to 30 minutes (previously 15 minutes). The value
  can be overridden.

  GitHub issue: #3033

Bug Fixes

• A classic queue with single active consumer option enabled could run into
  an exception after a restart or initial enablement of the management plugin.

  GitHub issue: #3072

Management Plugin

Bug Fixes

• A combination of HTTPS (TLS) settings and advanced HTTP server settings
  resulted in an exception.

  GitHub issue: #3039

• External stats collector is now restarted again if it fails for any reason.

  Contributed by @luos.

  GitHub issue: #3040

Consistent History Exchange Plugin

Enhancements

• When nodes are restarted, schema database tables used by this plugin are now reconciled
  with cluster peers the same way RabbitMQ core does it.

  GitHub issue: #3067

Recent History Exchange Plugin

Enhancements

• When nodes are restarted, schema database tables used by this plugin are now reconciled
  with cluster peers the same way RabbitMQ core does it.

  GitHub issue: #3067

Delayed Message Exchange Plugin

Enhancements

• When nodes are restarted, schema database tables used by this plugin are now reconciled
  with cluster peers the same way RabbitMQ core does it.

  Contributed by @mwfriedm.

  GitHub issue: rabbitmq/rabbitmq-delayed-message-exchange#163

Last Value Cache Exchange Plugin

Enhancements

• When nodes are restarted, schema database tables used by this plugin are now reconciled
  with cluster peers the same way RabbitMQ core does it.

  GitHub issue: rabbitmq/rabbitmq-lvc-exchange#28

Web MQTT Plugin

Bug Fixes

• MQTT-over-WebSockets client connections were not accounted for by the file handle tracking mechanism (metric and resource alarm).

  GitHub issue: #3076

Dependency Upgrades

None in this release.

Source Code Archives

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