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
andcluster_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 makerabbitmq-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 makerabbitmq-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
andcluster_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
andcluster_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
andauth_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 from1.11.1
to2b1d66b5f4
jsx
was updated from2.11.0
to3.1.0
observer_cli
was updated from1.6.1
to1.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.