RabbitMQ 4.2.0-beta.1 is a preview of a feature release.
Breaking Changes and Compatibility Notes
Default value for AMQP 1.0 durable field.
Starting with RabbitMQ 4.2, if a sending client omits the header section, RabbitMQ assumes the durable field to be false complying with the AMQP 1.0 spec:
<field name="durable" type="boolean" default="false"/>
AMQP 1.0 apps or client libraries must set the durable field of the header section to true to mark the message as durable.
Team RabbitMQ recommends client libraries to send messages as durable by default.
All AMQP 1.0 client libraries maintained by Team RabbitMQ send messages as durable by default.
Release Highlights
SQL Filter Expression for Streams
AMQP 1.0 clients can now define SQL-like filter expressions when consuming from streams, enabling server-side message filtering.
RabbitMQ will only dispatch messages that match the provided filter expression, reducing network traffic and client-side processing overhead.
SQL filter expressions are a more powerful alternative to the AMQP Property Filter Expressions introduced in RabbitMQ 4.1.
RabbitMQ implements a subset of AMQP Filter Expressions Version 1.0 Committee Specification Draft 01 Section 6 including support for:
- Comparison operators (
=,!=,<>,>,<,>=,<=) - Logical operators (
AND,OR,NOT) - Arithmetic operators (
+,-,*,/,%) - Special operators (
LIKE,IN,IS NULL) UTCfunction- Access to the properties and application-properties sections
Examples
Simple expression:
header.priority > 4Complex expression:
order_type IN ('premium', 'express') AND
(customer_region LIKE 'EU-%' OR customer_region = 'US-CA') AND
UTC() < properties.absolute-expiry-time AND
NOT cancelledTo learn more, check out the new documentation guide on Stream Filtering.
Pull Request: #14184
New Tooling for More Automated Blue-Green Deployment Migrations from 3.13.x Clusters to 4.2.x
Blue-Green Deployment migration from RabbitMQ 3.13.x
to 4.2.0 is now easier to automate thanks to a new set of commands provided by rabbitmqadmin v2.
Incoming and Outgoing Message Interceptors for Native Protocols
Incoming and outgoing messages can now be intercepted on the broker.
This works for AMQP 1.0, AMQP 0.9.1, and MQTT.
What the interceptor does is entirely up to its implementation, for example it can validate message metadata, add annotations, or perform arbitrary side effects.
Custom interceptors can be developed and integrated via plugins.
Two new optional built-in interceptors were added to RabbitMQ:
- Timestamps for outgoing messages
- Setting client ID of publishing MQTT client
Detailed information can be found in the Message Interceptor documentation.
Khepri Enabled by Default for New Clusters
RabbitMQ supports two databases to store
metadata such as virtual hosts,
topology, runtime parameters, policies, internal users and so on: Mnesia and
Khepri. That metadata store is also at the heart of clustering in RabbitMQ. As
of RabbitMQ 4.2.0, Khepri is the default metadata store for new
deployments.
Khepri is based on the
same Raft consensus algorithm used by quorum queues and streams. The goal is to
have a consistent well defined behaviour around all queries and updates of
metadata across an entire cluster, especially when the cluster suffers
increased latency or network issues for instance. It also comes with increased
performance in several use cases, even though this was not a goal.
A new RabbitMQ 4.2.0+ node will use Khepri by default. If you upgrade an
existing node or cluster, it will continue to use whatever metadata store it
was using so far.
If you did not enable Khepri yet, it is recommended you enable
it:
rabbitmqctl enable_feature_flag khepri_db
Khepri will become mandatory in a future minor version. Mnesia support will be
dropped in a future major version. These exact versions are to be decided.