CODEWITHSUNDEEP
azureazure-servicebus-topics
Chris
Chris

Reputation: 311

Azure Topics - Multiple Listeners on Same Subscription

Is there a way to have multiple listening clients on one Azure Topic Subscription, and they all recieve ALL messages? My understanding is that the only implementation of a Subscription is that the Published message is only delivered to ONE client on that subscription, as it is like a queue.

Can these messages be copied to multiple clients using the same Subscription?

EDIT: Potential use case example

A server notifies all of its clients (web clients via browser, or application), that are subscribed to the topic, of an object that has changed its value

More simply, multiple PCs are able to see a data value change

EDIT 2: My setup/what I'm looking for

The issue that I am running into is that a message is marked as consumed by one client, and not delivered to the other client. I have 3 PCs in a test environment:(1 PC publishing messages (we'll call this the Publisher) to the topic, and 2 other PCs subscribed to the topic using the same SubscriptionName (We'll call these Client 1 and Client 2)).

So we have this setup:

  1. Publisher - Publishes to topic
  2. Client 1 - Subscibed using SubscriptionName = Test1
  3. Client 2 - Subscribed using SubscriptionName = Test1

The Publisher publishes 10 messages to the topic.

... And so on (Not all 10 messages are recieved by both Client 1 and Client 2)

I want the Clients to recieve ALL messages, like this:

... And so on.

Upvotes: 1

Views: 1534

Answers (3)

user694299
user694299

Reputation: 41

Yes, its a one-to-one implementation, but, if you have real concern about message processing completing in sequential order then it depends on the Receive mode.

You can specify two different modes in which Service Bus receives messages.

  1. Receive and delete.

In this mode, when Service Bus receives the request from the consumer, it marks the message as being consumed and returns it to the consumer application. This mode is the simplest model. It works best for scenarios in which the application can tolerate not processing a message if a failure occurs. To understand this scenario, consider a scenario in which the consumer issues the receive request and then crashes before processing it. As Service Bus marks the message as being consumed, the application begins consuming messages upon restart. It will miss the message that it consumed before the crash.

  1. Peek lock.

In this mode, the receive operation becomes two-stage, which makes it possible to support applications that can't tolerate missing messages.

Finds the next message to be consumed, locks it to prevent other consumers from receiving it, and then, return the message to the application.

After the application finishes processing the message, it requests the Service Bus service to complete the second stage of the receive process. Then, the service marks the message as being consumed.

If the application is unable to process the message for some reason, it can request the Service Bus service to abandon the message. Service Bus unlocks the message and makes it available to be received again, either by the same consumer or by another competing consumer. Secondly, there's a timeout associated with the lock. If the application fails to process the message before the lock timeout expires, Service Bus unlocks the message and makes it available to be received again. If the application crashes after it processes the message, but before it requests the Service Bus service to complete the message, Service Bus redelivers the message to the application when it restarts. This process is often called at-least once processing. That is, each message is processed at least once. However, in certain situations the same message may be redelivered. If your scenario can't tolerate duplicate processing, add additional logic in your application to detect duplicates. For more information, see Duplicate detection. This feature is known as exactly once processing.

Check this link for more details.

Upvotes: 0

Balasubramaniam
Balasubramaniam

Reputation: 421

It is not possible for both the client1 and client2 to get the same messsage.

To put it straight, when a message is received by client1 from a subscription and processed successfully, the message is removed from the subscription, so the client2 will not be able to receive the same message again.

Hope this clarifies.

Upvotes: 1

Architect Jamie
Architect Jamie

Reputation: 2589

Service Bus is a one-to-one or end-to-end messaging system.

What you need is Azure Event Hub or Event Grid.

Upvotes: 1

Related Questions