The transport is compatible with RabbitMQ broker version 3.4 or higher, either self-hosted or running on CloudAMQP.
|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();
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.