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

RabbitMQ `3.8.13` is a maintenance release. This release . is highly recommended for best forward compatibility with future RabbitMQ versions. explains what package repositories and tools can be used to provision latest patch versions of Erlang `22.3.x`. See upgrade and compatibility notes first if upgrading from an earlier release series (e.g. `3.7.x`). See the for general documentation on upgrades and for release notes of other releases. When upgrading to this release from `3.7.15` or an older version, extra care has to be taken. Because older RabbitMQ CLI tools can be incompatible with Erlang 22+ releases, RabbitMQ must be upgraded at the same time as Erlang. Alternatively the node can be upgraded to `3.7.18` on Erlang 21.3 first, then Erlang 22.3 or 23.x, then RabbitMQ to the most recent 3.8.x release. Any questions about this release, upgrades or RabbitMQ in general are welcome on the and . Nodes that had an unusually long name (e.g. 150 or more characters) could overflow message property lengths with the identifier they generated. Now the generated values are almost entirely decoupled from node name length. GitHub issue: Consumer utilisation metric has been renamed to consumer capacity which more accurately represents what it measures. The metric indicates the percentage of time that RabbitMQ has attempted a delivery to a consumer of a queue, and was allowed to do so by the and the number of currently unacknowledged deliveries. For queues that have no consumers, the metric now returns 0%. For consumers that accept all deliveries attempted, the metric will be around 100% (optimal). For queues that do have consumers but no traffic the metric will be at 100%. The assumption here is that consumers can absorb all the load. This case is intentionally treated differently from the one above with no online consumers. GitHub issue: Consumer utilisation metric has been renamed to consumer capacity which more accurately represents what it measures. See a more detailed note above in the Management plugin section. GitHub issue: Quorum queues now can be federated. GitHub issue: Exchange federation now supports a new option, `channelusemode`, which allows a single channel to be used for all federation link activity if set to `single`: ``` shell rabbitmqctl set_parameter federation-upstream dc-2 '{"uri":"amqp://dc2.messaging.coolcorp.local:5672", "channel-use-mode": "single"}' ``` This helps avoid a race condition between topology changes and message flow and the cost of topology operations reducing message transfer rates and increasing rate variability. The default value is `multiple`. It means that every link will use multiple channels (one for message transfer, one for topology changes, etc), which has been the case since rabbitmq/rabbitmq-federation#97. This is the recommended mode for most environments, and all environments with a mostly static topology. See for the background. GitHub issue: The plugin could run into unhandled exceptions. GitHub issue: Several settings of the plugin are now exposed to `rabbitmq.conf` and provide validations: ``` ini auth_backends.1 = oauth2 authoauth2.resourceserverid = aresourceserverid authoauth2.additionalscopeskey = acustomscopekey authoauth2.defaultkey = id1 authoauth2.signingkeys.id1 = /path/to/signing.key1.pem authoauth2.signingkeys.id2 = /path/to/signing.key2.pem ``` GitHub issue: JWT tokens now can be fetched from a JWKS endpoint provided using the `rabbitmqauthbackendoauth2.keyconfig.jwks_url` key in `advanced.config`. Contributed by Teo @teozkr Klestrup Rijezon. GitHub issue: `lager` was `cuttlefish` was `credentials_obfuscation` was `observer_cli` was To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.8.13.tar.xz` instead of the source tarball produced by GitHub.