Azure Service Bus - subscribers can independently subscribe to a subscription and share the same message?
I'm new to Azure Service Bus and have created successful pocs for creating a topic and a separate subscriber application to receive its message.
Based on this article, I quote: "A topic can have up to 2,000 subscriptions associated with it, each of which gets independent copies of all messages sent to the topic. One or more subscribers can independently subscribe to a subscription and compete for messages from it."
What I'm interested to do is to expand this for multiple applications to independently subscribe to the same topic, but not compete for them.
My current poc has one sender and two separate applications subscribed to the same topic and subscription. The behavior that I'm seeing is that if I post one message from the sender, either one of the two running subscribing applications will receive it; but not the other.
My question is if multiple, independent applications can receive the same topic message? Any advice would be greatly appreciated!
When you create a subscription to a topic it has a specific subscription name. Any consumer that then starts requesting messages for that subscription name will compete for messages on that subscription. If you want independent applications to each receive a copy of the message sent to a topic they will each have to create their own subscription to the topic. You can almost view each subscription as a queue unto itself being fed by the topic.
The example I'll give is of a college. The topic is "New Student" and each department within the college wants to receive a copy of a message for a new student. Thus each department would have it's own subscription. There would be "Music", "Billings", "Science", "Math" subscriptions, etc. Each of them subscribing to the New Student topic. In this way each department receives a copy of the new student message, or can even filter on things they care about if they want. If the department gets behind in processing these they can spin up more instances of the processor using the their subscription name, thus increasing their throughput in theory since more consumers are then competing for the messages in their subscription.
So, in your example, each application would need to either create it's own subscription or be assigned an unique subscription to start pulling from when it starts up. Note that if you let the application lifetime decide the lifetime of a subscription (meaning you create a subscription when the app starts and destroy it when the app closes) you need to be aware that if there are no active subscriptions then messages sent to the topic will simply be lost. You can however create a catch all subscription that only receives messages that are not delivered to any other subscription. It really depends on what you are trying to accomplish.
What you are looking for is not Service Bus but Event Hub. Event Hub is working exactly you describe and can also be accessed by means of AMQP.