Support separate Azure Service Bus subscriptions for same topic with different route

[alexthissen]

When creating subscriptions on the same topic, but with a different route, the component for Azure Service Bus should honor a separate ASB subscription per combination.

Currently the implementation for the Azure Service Bus pub/sub component will only honor one of the topic/route combinations. It seems the AppID-topic tuple is used to register a subscription. This does not allow multiple subscriber on the same topic in the same application.

Example: Topic: MyTopic Route: RouteA

Topic: MyTopic Route: RouteB

should give two subscriptions.

[jjcollinge]

@alexthissen thanks for raising this issue. @yaron2 I believe the current ASB implementation is consistent with the other pub sub on this; is this something we’d want to support? - I’m happy to add route to the subscription ID if so.

[alexthissen]

Any news on this?

[jjcollinge]

Nothing as of yet. I’m curious of the use case, could you expand it for me please? Why not have one handler that invokes 2 functions rather than dapr invoking 2 handlers with the same message?

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[dapr-bot]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.

[artursouza]

As of now, Azure Service Bus component in pubsub does offer a ConsumerID attribute. So, this can be achieved by having two separate pubsub components connecting to the same ASB endpoint but using a different ConsumerID each. This metadata attribute is not yet document, so I have created an issue to track that: https://github.com/dapr/docs/issues/1727

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[sadgit]

Nothing as of yet. I’m curious of the use case, could you expand it for me please? Why not have one handler that invokes 2 functions rather than dapr invoking 2 handlers with the same message?

This is an anti-pattern as the outcome of each event may differ. This would need a separate tally of which processors have completed and which need retrying.

[berndverst]

Solution (as suggested by Artur):

Create 2 Dapr PubSub components but initialized with different consumerID metadata value. Other than that and their component name (e.g. pubsub1, pubsub2) the components should be identical.

Since Dapr is intended to be used for microservice development, I do not see a common scenario where a single app would need to subscribe to the same topic twice.

A separate app would of course have a separate sidecar.

Given this highly unusual scenario I believe that defining multiple Dapr components (which connect to the same underlying service but using distinct consumerIDs) is more than sufficient.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: servicebus-pubsub-1
spec:
  type: pubsub.azure.servicebus
  version: v1
  metadata:
  - name: connectionString # Required when not using Azure Authentication.
    value: "Endpoint=sb://{ServiceBusNamespace}.servicebus.windows.net/;SharedAccessKeyName={PolicyName};SharedAccessKey={Key};EntityPath={ServiceBus}"
  - name: consumerID # Optional: defaults to the app's own ID
    value: "group1" 

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: servicebus-pubsub-2
spec:
  type: pubsub.azure.servicebus
  version: v1
  metadata:
  - name: connectionString # Required when not using Azure Authentication.
    value: "Endpoint=sb://{ServiceBusNamespace}.servicebus.windows.net/;SharedAccessKeyName={PolicyName};SharedAccessKey={Key};EntityPath={ServiceBus}"
  - name: consumerID # Optional: defaults to the app's own ID
    value: "group2" 

And subscriptions (as would be returned by /dapr/subscribe):

[
  {
    "pubsubname": "servicebus-pubsub-1",
    "topic": "newOrder",
    "route": "/payment",
    "metadata": {
      "rawPayload": "true",
    }
  },
  {
    "pubsubname": "servicebus-pubsub-2",
    "topic": "newOrder",
    "route": "/orders",
    "metadata": {
      "rawPayload": "true",
    }
  }
]