Skip to content

RabbitMQ 3.8.18

Compare
Choose a tag to compare
@rabbitmq-ci rabbitmq-ci released this 25 Jun 05:33
2f3987e

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

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.