question

l-dobrev avatar image
0 Votes"
l-dobrev asked SamaraSoucy-MSFT answered

Consuming Service Bus Topic with App Service that is scale-out

Currently it seems that receiving messages from a Service Bus Topic with an App Service that has been scaled-out (2 or more instances) requires jumping through hoops:

Subscribing to a Topic requires a preemptively created subscription.

If all instances share the same subscription messages are delivered to only one instance (as with a Queue).
This is not the desired behaviour!

  1. Possible solution: create multiple subscriptions, configure every instance to use a different one.
    This does not seem to be possible when using App Service.
    One configuration is shared for all App Service instances.

  2. Possible solution: every instance creates a subscription with a random name.
    This requires that App Service instances have Service Bus credentials with MANAGE permission, which is dangerous.
    This requires additional code that requires additional dependencies (on Azure Management API).

Using:

  • spring-boot-starter-parent:2.5.4

  • spring-messaging:5.3.9

  • azure-servicebus-jms-spring-boot-starter:2.3.5

Please advise on a reliable way to listen to an Azure Service Bus Topic with a scaled-out (2+ instance) App Service using JMS, so that every message is received by every instance.





azure-webappsazure-service-bus
· 2
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Have you observed this behavior? If so could you please share the code you are using to setup the subscription. The default behavior is to allow both instances to feed from the same subscription. Each subscription receives a separate set of messages so giving each instance its own subscription would result in them getting the same set of messages.

0 Votes 0 ·

Getting the same messages on both instances IS the expected behaviour.
Getting different set of messages is akin to a Queue, not a Topic.

0 Votes 0 ·

1 Answer

SamaraSoucy-MSFT avatar image
0 Votes"
SamaraSoucy-MSFT answered

Each topic subscription does indeed act like a queue would. Subscriptions exist in order to ensure that there is a distinction between receivers working on the same set of messages (a single subscription or a queue) and receivers working on their own distinct copy of messages (multiple subscriptions).

Lets say I have a topic that is receiving requests to resize photos. I want to receive messages to resize the photo and a separate set of messages for logging. Logging might be fine with a single receiver, but as resizing work scales up maybe I want to have three receivers. I don't want to resize each photo three times, one for each receiver, I want each request to be handled once for resize and once to log. In this case I would make two subscriptions. The logger would feed from one subscription and all three resize workers would feed from the other. Auto-scaling usually reflects this- each instance is doing the same job, so you don't want duplicate messages in order to avoid doing duplicate work.



· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Using Azure Service Bus Premium and using the Azure Service Bus JMS library, the behavior you are looking for is available- specifically that it will create a subscription only for the life of a receiver: https://docs.microsoft.com/en-us/azure/service-bus-messaging/java-message-service-20-entities#unshared-non-durable-subscriptions Outside of that, your second option is most common that I am aware of. You can have it call a separate service to manage the subscriptions to separate responsibility and/or give the additional permissions only for that specific topic to minimize the security impact: https://docs.microsoft.com/en-us/azure/service-bus-messaging/authenticate-application#resource-scope

0 Votes 0 ·