dapr
/
docs
mirror of https://github.com/dapr/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

add details for single active consumer parameter 

Signed-off-by: Arthur Poiret <dropsnorz@gmail.com>
This commit is contained in:
Arthur Poiret 2024-07-18 18:33:55 +00:00
parent 1841418449
commit cd0a2bd7e9
1 changed files with 7 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
daprdocs/content/en/reference/components-reference/supported-pubsub/setup-rabbitmq.md
View File

@ -453,7 +453,13 @@ If you set both component-level and message-level TTL, the default component-lev
## Single Active Consumer
Enable RabbitMQ [Single Active Consumer](https://www.rabbitmq.com/docs/consumers#single-active-consumer) parameter on queues.
The RabbitMQ [Single Active Consumer](https://www.rabbitmq.com/docs/consumers#single-active-consumer) setup ensures that only one consumer at a time processes messages from a queue and switches to another registered consumer if the active one is canceled or fails. This approach might be required when it is crucial for messages to be consumed in the exact order they arrive in the queue and if distributed processing with multiple instances is not supported.
When this option is enabled on a queue by Dapr, an instance of the Dapr runtime will be the single active consumer. To allow another application instance to take over in case of failure, Dapr runtime must [probe the application's health]({{< ref "app-health.md" >}}) and unsubscribe from the pub/sub component.
{{% alert title="Note" color="primary" %}}
This pattern will prevent the application to scale as only one instance can process the load. While it might be interesting for Dapr integration with legacy or sensible applications, you should consider a design allowing distributed processing if you need scalability.
{{% /alert %}}
```yml
apiVersion: dapr.io/v2alpha1
@ -469,10 +475,6 @@ spec:
singleActiveConsumer: "true"
```
{{% alert title="Note" color="primary" %}}
The Dapr runtime acts as the single active consumer from RabbitMQ's perspective. To allow another application instance to take over in case of failure, Dapr must [probe the application's health]({{< ref "app-health.md" >}}) and unsubscribe from pub/sub component.
{{% /alert %}}
## Related links
- [Basic schema for a Dapr component]({{< ref component-schema >}}) in the Related links section