rabbitmq/rabbitmq-server v3.8.18-rc.1

RabbitMQ 3.8.18-rc.1

on GitHub

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.