﻿# RabbitMQ Transport


Provides support for sending messages over [RabbitMQ](https://www.rabbitmq.com/) using the [RabbitMQ .NET Client](https://www.nuget.org/packages/RabbitMQ.Client/).

## Broker compatibility

The transport is compatible with RabbitMQ broker version 3.10.0 or higher.

The `stream_queue` and `quorum_queue` [feature flags](https://www.rabbitmq.com/feature-flags.html) must be enabled because the [delay infrastructure](delayed-delivery.md) requires [at-least-once dead lettering](https://blog.rabbitmq.com/posts/2022/03/at-least-once-dead-lettering/).

The [RabbitMQ management plugin](https://www.rabbitmq.com/docs/management) must be enabled, and the plugin's [statistics and metrics collection must not be disabled](https://www.rabbitmq.com/docs/management#disable-stats). The port that the management API is using needs to be accessible by the transport. The default port is `15672` for HTTP and `15671` for HTTPS. See [Configuring RabbitMQ management API access](connection-settings.md#configuring-rabbitmq-management-api-access) for configuration options.

The broker requirements can be verified with the [`delays verify`](operations-scripting.md#delays-verify) command provided by the command line tool.


### Hosted broker options

The transport has been confirmed to work with the following hosting providers:

- [Amazon MQ](https://aws.amazon.com/amazon-mq/)
- [CloudAMQP](https://www.cloudamqp.com/)

> [!NOTE]
> Other hosted options may work as long as they meet the requirements specified above.

## Transport at a glance

|Feature                    |   |
|:---                       |---
|Transactions               |ReceiveOnly
|Pub/Sub                    |Native
|Timeouts                   |Native
|Large message bodies       |Broker can handle arbitrary message size within available resources, very large messages via data bus
|Scale-out             |Competing consumer
|Scripted Deployment        |Not supported
|Installers                 |Mandatory
|Native integration         |[Supported](native-integration.md)
|Case Sensitive             |Yes
|Aspire integration         |[Yes](/platform/aspire/index.md#configuring-the-transport-rabbitmq)

## Configuring the endpoint

To use RabbitMQ as the underlying transport:

<!-- snippet: rabbitmq-config-basic -->

```cs
endpointConfiguration.UseTransport<RabbitMQTransport>();
```

<!-- endsnippet -->

The RabbitMQ transport requires a connection string to connect to the broker. A [clustered](https://www.rabbitmq.com/clustering.html) configuration is recommended. See [connection settings](/transports/rabbitmq/connection-settings.md) for options on how to provide the connection string.

> [!NOTE]
> The existing API surface with `UseTransport<T>()` is supported via a [shim API](https://en.wikipedia.org/wiki/Shim_(computing)) to ease migration. However, it is recommended to switch to the new transport configuration API to prepare for future upgrades of NServiceBus.


### Routing topology

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:

<!-- snippet: rabbitmq-config-useconventionalroutingtopology -->

```cs
var transport = endpointConfiguration.UseTransport<RabbitMQTransport>();
transport.UseConventionalRoutingTopology(QueueType.Quorum);
```

<!-- endsnippet -->

See the [routing topology documentation](/transports/rabbitmq/routing-topology.md) for further details.


## Advantages and disadvantages


### Advantages

 * Provides [native reliability](https://www.rabbitmq.com/reliability.html) and [high-availability](https://www.rabbitmq.com/docs/quorum-queues#availability) features.
 * Offers a native publish-subscribe mechanism; therefore it doesn't require NServiceBus persistence for storing event subscriptions.
 * Wide range of [supported clients](https://www.rabbitmq.com/devtools.html) allows for integrating the system with applications written in other languages using native RabbitMQ features.
 * Supports the [competing consumers](https://www.enterpriseintegrationpatterns.com/patterns/messaging/CompetingConsumers.html) pattern out of the box. Messages are received by instances in a round-robin fashion without additional configuration.


### Disadvantages

 * Doesn't handle [network partitions](https://www.rabbitmq.com/partitions.html) well; partitioning across a WAN requires dedicated features.
 * Requires careful consideration for duplicate messages, e.g. using the [outbox](/nservicebus/outbox/index.md) 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](https://www.rabbitmq.com/services.html).

## Controlling delivery mode

In AMQP [the `delivery_mode`](https://www.rabbitmq.com/amqp-0-9-1-reference.html) 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 `non-persistent`.

> [!CAUTION]
> Any failure in transmission or issues in the broker will result in the message being lost

To request `non-persistent` delivery, use the following `{Send|Publish|Reply}Options` as shown below.

<!-- snippet: rabbitmq-non-persistent-delivery-mode -->

```cs
var options = new SendOptions();

options.RouteToThisEndpoint();
options.UseNonPersistentDeliveryMode();

await context.Send(new MyMessage(), options);
```

<!-- endsnippet -->

