What happens if you have let's say 4 instances of a webapp, and a lot of messages queued up in the service bus queue (meant to reach all the 4 instances) and the webapp scales down to only 2 instances. Will the messages, in the service bus that were meant for the other two instances that were removed, be stuck in the queue until the time to live is exceeded and then removed or does the service bus understand that there are not 4 instances anymore and therefore it doesn't need to send out messages to 4 instances?
I'm not sure if this is the correct but from my understanding there usually is a topic and then multiple subscriptions? will the service bus understand when one of the instances (who has a subscription) is gone and then removes the message meant for that subscription while the message is queued up (a lot of other messages before it)?
Sorry if the question is a little dumb but I couldn't find any answers on the internet.
Will the messages, in the service bus that were meant for the other two instances that were removed, be stuck in the queue until the time to live is exceeded and then removed
Service Bus queues and topic subscriptions provide a secondary sub-queue, called a dead-letter queue (DLQ).
The purpose of the dead-letter queue is to hold messages that cannot be delivered to any receiver, or simply messages that could not be processed. More details please refer to the document.
does the service bus understand that there are not 4 instances anymore and therefore it doesn't need to send out messages to 4 instances?
Service Bus Queues offer First In, First Out (FIFO) message and Service Bus queue message is received and processed by only one message consumer. If we have multiple web instance, when a quest arrive then WebApp LoadBlance (ARR) will assign the request to the corresponding instance to process the message. If the instance has been removed, the WebApp loadBlance (ARR) will assign the request to the existing instance.
will the service bus understand when one of the instances (who has a subscription) is gone and then removes the message meant for that subscription while the message is queued up (a lot of other messages before it)?
As mentioned above, it is assigned by WebApp LoadBlance not Service bus. How to consume message is depended on your WebApp.
Related
We have a .NET Core 3.1 web-API application that listens to an Azure Service Bus queue. We would like to get more information about the consumer of the messages on the queue - within our workflow, there should only be one (designated) consumer of a given queue, however we suspect there are multiple consumers. We suspect this because there are no application log entries on the designated consumer application logs when (and after) a message on the queue is being processed.
To attempt to determine the consumer of a queued entry I have looked at the Service Bus Logs and queries related to AzureActivity and AzureDiagnostics however I couldn't find specific information about a message(s)/item(s) on a given queue
Can anyone shed any light on how I can find details about the consumer of a queued item ?
I read myself a bit about azure service bus. There many examples how I can set it up, create a queue and get information from the queue.
Now I have a question. When I have a second responder (for example an azure function / With different functionality) I must create a new queue? Or how is routing from the message between these two responders.
Regards
If you want your message to be received and processed by more than one receivers, you should look into Service Bus Topics.
Service Bus Topics are meant for one to many mapping, where a message sent to a Topic can be received from different Subscriptions.
In Azure Service Bus topic, I am having two subscriptions
subscription1 and subscription2. I am sending one message to topic.
In subscription1 the message got abandoned and in subscription2 the
message got processed. Whether the abandoned message in subscription1
will again be sent to both subscriptions or only subscription in
which it got abandoned.
I am also a little bit confused whether the dead letter queue will be common
for all subscriptions or each subscription will have a separate dead
letter queue?
Please clarify me on the above two points.
Subcriptions are independent. Abandon affects just the one where it was abandoned, and dead letter queues are separate.
One caveat is that if you want to resubmit messages from DLQ, you can't send them directly to the corresponding subscription, it has to go through the topic again.
I have following requirement
Message published to the Topic/Queue
Multiple consumers subscribed to the Topic/Queue. So our requirement is to only one consumer should listen to the message. That means no other consumer can get the same message.
I feel queue would be the best fit. But I have advise from our architect to check whether we can achieve it from Topics?.
So any body please let me know whether we can achieve it through Topics and also pros and constrains?
Thanks.
Azure Service Bus Queue is a single message queue. You send it a message and the message receiver will get the message and be able to process it accordingly. Each message will only be handled once.
Azure Service Bus Topic is a more robust message queue than Azure Service Bus Queue. With Topics there can be multiple Subscriptions configured to catch messages based on a Filter. If multiple Subscriptions have a Filter that matches an incoming message, then each of those Subscriptions will get a copy of the messages. With Topics it's up to you to configure the Subscription Filters according to your projects needs.
If you know a message only needs to be handled once in your system and the message queue is being used by a single message receiver application (single or multiple hosted instances) then Azure Service Bus Queue is likely the tool for the job.
We are trying to use Azure Topic/Subscriptions to distribute changes in one domain to others services that need to update their local cache. So we have one guy publishing a message and a bunch, not knowing of eachother, listening to this topic queue.
I might have missunderstod the idea of the azure TopicDescription.DefaultMessageTimeToLive but I thought it indicated that as long as the message is still within this timeout, it will be delivered, regardless if the subscriber is "online" at the time of publishing.
But this does not seem do be the case?
What I want to accomplish is that if I have a DefaultMessageTimeToLive set to 10 minutes, all subscribers are guaranteed to get all published messages if they have a downtime lower than 10 minutes.
When I try it, I do not receive messages unless I am listening at the time of publishing. (Added remark: Each receiving queue has its own unique name)
Have I got it wrong or is there a configuration I missed?
If you want a topic available to N subscribers (listeners), then you need N subscriptions. Subscriptions are "virtual" FIFO queues. If a subscription has more than one listener, they "compete" for the next message. This pattern is often termed the “competing consumer” pattern. Read more at Service Bus Queues, Topics, and Subscriptions and How to Use Service Bus Topics/Subscriptions.
The TopicDescription.DefaultMessageTimeToLive just defines how long a message is available before it is moved to the dead-letter queue.