I am using azure service bus subscription and Topics for sending orders and getting orders. We have a windows app which pulls orders using web api from azure service bus subscription.
Suppose if user login and got 5 orders. If user log out from the windows app then we unlocks the messages from azure service bus. and if user logs again after 5 min or less then we are not getting all the orders from azure service bus. Its coming like 3 or 4 sometimes.
Can anyone help me on this issue, why I am not getting all the 5 orders again. I am using ReceiveBatch method of subscriptionclinet for pulling messages.
I suspect you're running into a delivery count issue here. Assuming I understood correctly what you're saying, the windows app pulls the messages in a PeekLock mode. Once message is processed, you complete it. Otherwise, upon exit from the application, you abandon the messages. If you not done processing messages, and user quits, the message is abandoned while DeliveryCount is increased. Once DeliveryCount exceed the maximum set on the entity, the message is deadlettered and will not be delivered anymore.
Check your MaxDeliveryCount on the entity
Check you entity`s DLQ to verify if this is the behaviour
In case they are DLQed, I suggest to look into centralising your DLQs for easier error handling
Related
I am sending messages from my custom application to servicebus. And recently I have added some messages for testing purposes. But later I realized that I have picked the wrong Queue. Now I don't want the Test messages to be in this queue. Is there any possible way to delete those recently added test messages from my queue?
As mentioned by Pedro in his comment you can use service bus explorer: https://github.com/paolosalvatori/ServiceBusExplorer to peek and delete the message from the queue. Alternatively, you can call the service bus REST API or write your own code to consume that message.
As an alternative you can use Service Bus Cloud Explorer which runs in the browser with logged-in user Azure account by default and have a delete and a purge functionality.
Keep in mind that it will take time to clear up queues or subscriptions. More messages it needs to delete; the more time it would take.
I am using Azure Service Bus Queues in one of my .net core application to receive the messages from the Queue in the FIFO order. Once received the message from the Queue, then I have processed the business logic with each message. Once processed the business logic with each message then I am trying to delete the message from Queue with following line of code:
await _messageReceiver.CompleteAsync(message.SystemProperties.LockToken);
But for the few messages, I am unable to delete the messages from Queue. Because lock on the message expired even though I configured the “Lock Duration” 3 minutes on Service Bus Queue.
I am getting the following error while deleting/completing the message from Service Bus Queue:
Exception Type: System.InvalidOperationException
Exception Message: Operation is not valid due to the current state of the object.
These are properties I configured on the Azure Service Bus Queue:
Max Delivery Count =1
Lock Duration=3 minutes
There are a few reasons why you are not able to delete the messages in Azure Service Bus Queue.
Challenge with Lock Duration
The first challenge is Time, specifically lock duration for every message once they have been retrieved. The problem is that the messages must be displayed in the UI and then provide time for the customer to choose the messages to be resubmitted or deleted. The solution would be to ask the customer to increase the lock duration, but this is not possible due to several reasons. Firstly, increasing lock duration might not be possible due to customer integration, so we cannot depend on that.
Read more on this blog post on how to overcome the challenge.
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.
I have implemented the azure web job to consume messages from azure service bus. Service bus trigger works fine for new messages arrived to service bus but its not picking up the messages that were already available on the service bus before service start. Is there any configuration to get existing messages to the web job?
Due to some reason, some messages got abandon. What are the best ways to reprocess these messages.
If you get messsage and can't complete or abandon it 10 times(default), the message will go dead queue.
You can get dead queue like this.
_messagingFactory.CreateQueueClient(QueueClient.FormatDeadLetterPath(QueueDescription.Path), ReceiveMode.PeekLock);
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.