Queues

Used to queue messages for the backend.

Requirements

• Competing consumer
  • The implementation must support competing consumers, ie if there are multiple registered consumers, each message will only be handled by one of them.
  • From the documentation this includes the at least the following:
    • Apache Kafka
    • Azure Service Bus Queues
    • RabbitMQ
    • Redis Streams
  • From testing we know that this is also suported by Azure Service Bus Topics
• Single threaded
  • The implementation must only handle one message at a time
• Retry
  • A message that isn't explicitly handled by a consumer goes back on the queue.
• Infinite(ish) timeout
  • A consumer needs to be able to work on a message for as long as it takes, even hours, without the message being put back on the queue
• Offline messages
  • We need to be sure that messages sent while all consumers are offline will be received once it comes online

Possible Implementations

Azure Service Bus Topics

Tested with the component pubsub.azure.servicebus.topics see https://docs.dapr.io/reference/components-reference/supported-pubsub/setup-azure-servicebus-topics/.

Previous versions referred to this as pubsub.azure.servicebus, and the documentation seems to mix the topics with the queues in some places. For instance testing shows that pubsub.azure.servicebus.topics support competing consumers, even though the documentation says it's only for pubsub.azure.servicebus.queues

The following non-default configuration should be set:

• disableEntityManagement = false: This allows topics to be autogenerated on startup. This is not a requirement but definitely makes deployment easier
• maxConcurrentHandlers = 1: This configures the consumer to only handle one message at a time
• handlerTimeoutInSec = {some high value}: This is the setting that controls how long it will lock the message from other consumers, before returning it to the queue whether or not it is done. There are some other settings that sound like a better fit, but googling and testing shows that their defaults are fine. The documentation doesn't indicate what the limits are, and inspecting the code hints that "0" might be treated as infinite, but I've been unable to test this so far.

To ensure that all backends for a given roadnet competes for messages it is important that they either have the same consumerID or appId. Since we reuse the same component configuration for all roadnets it's easier to use the appId. For this reason it is recommended to not set consumerID for the queue pubsub component.

RabbitMq (Only partially tested)