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

Question

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.

Answer 1

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.

Answer 2

I'm trying to scale-out my app and I'm having a problem, only oneof my apps is getting a message from a subscription and all others don't do anything. It seems like an one app is the master and it reads all messages and others are slaves.

How do i solve this ?

The app has min replica 5 and max 15