0

This may be a stupid question, but I can't find a definite unambiguous answer by reading the documentation.

This is what I understand from the documentation:

So assume you have a queue, you can send multiple messages to it, and have multiple clients/readers connected to the queue. In this case each message will be received by just one client/reader.

Now assume you have made a topic, and send messages to that. And you have several clients/readers who each make there own subscription to the topic; In this case each client/reader will receive all the messages send to the topic.

But this is what I want to know:

Is it possible to create a topic, with one subscription; and then connect multiple clients/readers to that same subscription? And if so; can I then assume that each message will be received by only one client/reader?

(Or, is this not possible, and do we need to create a queue; then link that queue to the subscription, and create multiple readers on the queue.)

PS; I know that it makes no sense to have a topic with only one subscription. What I actually have in mind is a topic with multiple subscriptions which each may have zero, one, or more clients reading from it.

2 Answers2

1

Is it possible to create a topic, with one subscription; and then connect multiple clients/readers to that same subscription?

Yes, it is certainly possible to do so. Multiple clients/readers can read from a single subscription.

And if so; can I then assume that each message will be received by only one client/reader?

Yes, each message will be received by only one client/reader. A client can read the message in either Peek/Lock mode or Receive/Delete mode to guarantee exclusivity.

When a message is fetched in Peek/Lock mode, the client which receives the message acquires exclusive lock on the message for certain duration and during that duration the message will not be visible to other clients. If the client processes the message and deletes it, then it won't be visible to other clients ever. If the client is not able to process the message during that duration, the message becomes visible to other clients after that and other clients can also read the message.

When a message is fetched in Receive/Delete mode, as soon as the client receives the message, it will be deleted from the server thus no other client can get that message.

A client can also get the message in Peek mode but in that case same message is available to all other clients as well.


In your scenario, you're essentially using a subscription as a queue and you may be better off just using a queue instead of using topic and subscription.

Gaurav Mantri
  • 128,066
  • 12
  • 206
  • 241
  • Thanks for the clear answer. In my scenario each micro-service should get it's own topic, and other microservices are free to subscribe on changes. In some cases, each "pod" should create it's own "private" subscription, and in some cases there could be a "shared" subscription setup that spreads the load to all pod's of the same micro service. – Frederick Grumieaux Dec 02 '19 at 13:11
0

Your understanding of the documentation is perfectly correct as you said. For your question, you should create a Topic with multiple subscriptions and then each client can receive messages allocated to them via the topic.

Actually, Service Bus topics and subscriptions support a publish/subscribe messaging communication model. When using topics and subscriptions, components of a distributed application do not communicate directly with each other; instead, they exchange messages via a topic, which acts as an intermediary between the two.

enter image description here

if you do not want to use the above model, you can go for eventhub, which will suit your requirement. you can create Partitions and Applications as you need.

Sajeetharan
  • 216,225
  • 63
  • 350
  • 396
  • Oddly I'm still having the same question after reading your reply. What I need to read is one of the two following answers: A) yes: you can connect multiple readers to the same subscription; or B) No, you need to link the subscription to a queue. – Frederick Grumieaux Dec 01 '19 at 17:08
  • Answer is B, but instead of queue it should be topic https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted – Sajeetharan Dec 01 '19 at 17:16