This version of the transport is compatible with RabbitMQ broker version 3.10.0 or higher either self-hosted or running on Amazon MQ or CloudAMQP. For previous versions of RabbitMQ it is recommended to upgrade RabbitMQ or select an earlier version of the transport.
The broker requirements can be verified with the
delays verify command provided by the command line tool.
|Large message bodies||Broker can handle arbitrary message size within available resources, very large messages via data bus|
|Scripted Deployment||Not supported|
To use RabbitMQ as the underlying transport:
Routing topologies are used to control how queues, exchanges, and bindings are created on the RabbitMQ broker. Selecting a routing topology is mandatory. For new deployments, the
ConventionalRoutingTopology (previously the default) should be selected:
var transport = endpointConfiguration.UseTransport<RabbitMQTransport>(); transport.UseConventionalRoutingTopology(QueueType.Quorum);
See the routing topology documentation for further details.
- Provides native reliability and high-availability features.
- Offers a native publish-subscribe mechanism; therefore it doesn't require NServiceBus persistence for storing event subscriptions.
- Wide range of supported clients allows for integrating the system with applications written in other languages using native RabbitMQ features.
- Supports the competing consumers pattern out of the box. Messages are received by instances in a round-robin fashion without additional configuration.
- Doesn't handle network partitions well; partitioning across a WAN requires dedicated features.
- Requires careful consideration for duplicate messages, e.g. using the outbox feature or making all endpoints idempotent.
- Many organizations don't have the same level of expertise with RabbitMQ as with other technologies, such as SQL Server, so it may require additional training.
- May require additional costs of commercial RabbitMQ license and support.
In AMQP the
delivery_mode controls how the broker treats the message from a durability standpoint. NServiceBus will default to
persistent in order to prevent message loss. To optimize for higher throughput this can be changed to
See the the non-durable messaging documentation for more details.