Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.8.18.md

RabbitMQ `3.8.18` is a maintenance release that includes a security patch. This release addresses an undisclosed vulnerability with CVSS 3.1 (low): Our team would like to thank Fahimhusain Raydurg for the vulnerability and Patrik Ragnarsson from CloudAMQP for contributing a fix. RabbitMQ releases are distributed via , , and . This release and . explains what package repositories and tools can be used to provision modern Erlang versions. See the for general documentation on upgrades and for release notes of other releases. If upgrading from a`3.7.x` release, see upgrade and compatibility notes first. If upgrading from a `3.6.x` or older , first upgrade to and then to this version. Any questions about this release, upgrades or RabbitMQ in general are welcome on the and . no longer uses randomized delays to avoid the inherent race condition during . 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. `clusterformation.randomizedstartupdelayrange.min` and `clusterformation.randomizedstartupdelayrange.max` configuration keys will no longer have any effect. GitHub issue: 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: Build system targets now use `hostname(1)` in a way that is compatible with Solaris. Contributed by Pavel @tropikhajma Heimlich. GitHub issue: Queue deletion could run into an exception in some rare cases. Contributed by @tomyouyou. GitHub issue: 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: In certain double stack (IPv4 and IPv6) environments, the plugin would start a single listener but register two

That extra non-existent listener would make `rabbitmq-diagnostics drain` fail as it disables all registered listeners. GitHub issue: Kubernetes mechanism no longer uses randomized delays to avoid the inherent race condition during . 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. `clusterformation.randomizedstartupdelayrange.min` and `clusterformation.randomizedstartupdelayrange.max` configuration keys will no longer have any effect. GitHub issue: AWS mechanism no longer uses randomized delays to avoid the inherent race condition during . 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. `clusterformation.randomizedstartupdelayrange.min` and `clusterformation.randomizedstartupdelayrange.max` configuration keys will no longer have any effect. GitHub issue: 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 scenarios but otherwise should be avoided. GitHub issue: `authhttp.connectiontimeout` and `authhttp.requesttimeout` 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 Miosz @SzumiecM Szumiec. GitHub issue: `jose` was updated `jsx` was updated `observer_cli` was updated 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.