66 lines
2.9 KiB
Markdown
66 lines
2.9 KiB
Markdown
## RabbitMQ 4.2.0
|
|
|
|
RabbitMQ 4.2.0 is a new 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](https://github.com/rabbitmq/rabbitmq-server/pull/13918) 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](https://www.rabbitmq.com/client-libraries/amqp-client-libraries) send messages as durable by default.
|
|
|
|
|
|
## Features
|
|
|
|
### 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](https://www.rabbitmq.com/docs/next/plugins).
|
|
|
|
Two new optional built-in interceptors were added to RabbitMQ:
|
|
1. Timestamps for outgoing messages
|
|
2. Setting client ID of publishing MQTT client
|
|
|
|
Detailed information can be found in the [Message Interceptor](https://www.rabbitmq.com/docs/next/message-interceptors) documentation.
|
|
|
|
### Khepri enabled by default
|
|
|
|
RabbitMQ supports two databases to [store
|
|
metadata](https://www.rabbitmq.com/docs/metadata-store) 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](https://www.rabbitmq.com/docs/metadata-store#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](https://www.rabbitmq.com/docs/metadata-store/how-to-enable-khepri):
|
|
|
|
```
|
|
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.
|