RabbitMQ Transport Upgrade Version 6 to 7

Version 7 of the RabbitMQ transport is focused on fully supporting quorum queues.

Minimum broker version

Version 7 relies on quorum queue features introduced in RabbitMQ 3.10.0, so the transport now requires that all RabbitMQ nodes be on version 3.10.0 or above.

In addition, the stream_queue and quorum_queue feature flags must be enabled.

The broker requirements can be verified with the delays verify command provided by the command line tool.

See the minimum broker requirements documentation for more details.

New version of the delay infrastructure

The original v1 delay infrastructure can lose messages due to the lack of safety guarantees when dead-lettering messages with classic queues.

Version 7 introduces a new v2 delay infrastructure that uses quorum queues instead of classic queues. The v2 infrastructure can exist side-by-side with the previous v1 infrastructure. Messages in the v1 infrastructure are not automatically migrated, but they can be manually migrated with the delays migrate command provided in the new command line tool.

UseConventionalRoutingTopology now has a mandatory QueueType parameter

To control what type of queue the endpoint will use, a QueueType parameter has been added to UseConventionalRoutingTopology:

var transport = endpointConfiguration.UseTransport<RabbitMQTransport>();
transport.UseConventionalRoutingTopology(QueueType.Quorum);

var transport = endpointConfiguration.UseTransport<RabbitMQTransport>();
transport.UseConventionalRoutingTopology();

The parameter controls what type of queues the endpoint will create if installers are enabled.

UseDirectRoutingTopology now has a mandatory QueueType parameter

To control what type of queue the endpoint will use, a QueueType parameter has been added to UseDirectRoutingTopology:

var transport = endpointConfiguration.UseTransport<RabbitMQTransport>();
transport.UseDirectRoutingTopology(QueueType.Quorum);

var transport = endpointConfiguration.UseTransport<RabbitMQTransport>();
transport.UseDirectRoutingTopology();

The parameter controls what type of queues the endpoint will create if installers are enabled.

Installers no longer ignore queue type mismatches when declaring queues

Now that there is a way to control what sort of queue type is created when installers are enabled, the queue creation installer will once again throw an exception if there is a mismatch between the type of queue it declares and the type of the queue that already exists on the broker.