0
votes

What is the lifespan for a client's subscription (i.e. subscriber) to a topic?

Conditions

Within my development environment, I've been creating SubscriptionClient instances for various service bus topics.

My fear is that for every subscription client that I instantiate for a given topic, I could be inadvertently duplicating messages going out (each time I subscribe to a given topic).

My Theory

The basis for my concern is due to what I believe is one of the traits of a Service Bus, durable messages. Hence, I thought durable messages are guaranteed to be delivered in case of spotty connectivity.

So what happens when one application (out of several) loses connectivity with the service bus for a day and then the next day the app is relaunched and a new subscription client instance is instantiated? Will the app resume receiving messages that were pending delivery while the other apps have already processed those same messages due to their own subscriptions?

In conclusion, what is the lifespan for a client's subscription (i.e. subscriber) to a topic?

Appendix

References:

Auto-expire orphaned Subscription (Azure ServiceBus Messaging SubscriptionClient)

https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-performance-improvements

https://weblogs.asp.net/sfeldman/asb-subs-with-correlation-filters

1

1 Answers

0
votes

What is the lifespan for a client's subscription (i.e. subscriber) to a topic?

A bit broad of a question. If you refer to a client connecting to the broker, as long as there's an uninterrupted underlying connection the client will be connected to the subscription. In case you're referring to the logical subscriber, whenever the logical subscriber connects. Which could be 24/7/365 or occasional. That lifespan is then defined by whatever your system is going to do.

So what happens when one application (out of several) loses connectivity with the service bus for a day and then the next day the app is relaunched and a new subscription client instance is instantiated?

A new client instance is still an instance of your logical subscriber, correct? As long as that's the case, you will receive the events for that subscriber. What's important is to note that the new client instance should connect to the same subscription and not try to create a new subscription. If it does, then you will definitely have duplicates.

Will the app resume receiving messages that were pending delivery while the other apps have already processed those same messages due to their own subscriptions?

If you running several app instances connecting to the same topic, if one is going down, the rest will continue processing messages. There will be no pending messages. If you have other apps consume messages from different topics then yes, your re-connecting app will be receiving all the messages that were published while it was down.

You might want to look at the Competing Consumers pattern. A subscription is a queue with competing consumers.