I send a message to ASB, some data (a long task) will start being processed, but the processing fails miserably (someone turns off the computer/out of memory/whatever). How should I handle this situation? Like putting the queue back on the bus? Do I need to create my own monitoring/requeueing unit?
Azure ServiceBus has an internal retry policy. If a message fails to deliver, it will be send back to the queue automatically.
When creating a queue or a topic/subscription you can specify the MaxDeliveryCount.
QueueDescription.MaxDeliveryCount
SubscriptionDescription.MaxDeliveryCount
Default value is 10. A message is automatically deadlettered after this number of deliveries.
Related
Problem: I have a Azure Topic Topic1 with Subscriptions Subscription-A, Subscription-B, Subscription-C
Each Subscription is listen to by an Azure function and it uses the message to perform unique action like charging customer or Updating another subsystem etc.
If the execution in one of the functions results in error , I would like to requeue the message into that specific subscription for execution after a delay say 1 min. not right way. [ Currently, If the function results in error, message is retried right away couple of times before pushing to dead letter. Looks like default behavior by Azure service bus and functions]
I can not resend a message to Topic1 as that message would be read by all the 3 subscriptions. I don't want this as the other message were processed successfully by the respective subscription/functions. This requeued message should be filtered out by other subscriptions on this topic.
Any ideas or suggestion would be of great help.
I'm more used to Service Bus Queue but have challenges when using it with Azure Function App.
We have Azure Function App which reads data from Service Bus Queue through ServiceBugTrigger. Per this link, Azure Function App manage Queue message PeekLock internally (at the queue trigger and function execution end), we do not require to Complete() message at the end of the process.
My queue message lock duration is set to 3min (which is enough for my execution, I would say more than my requirement). I also applied other required parameters to treat message well like,
"serviceBus": {
"maxAutoRenewDuration": "00:05:00",
"maxConcurrentCalls": 10,
"prefetchCount": 0
}
I am getting LOCK DURATION EXPIRED error frequently with this implementation. Really no idea what's happening here, Any clue?
I am used to Service Bus Queue and aware with each parameter function. Also, have configured each parameter per requirement.
This happens when your maxAutoRenewDuration is more than the lock duration at servicebus side.
You should check the lock duration specified at Service bus queue side. Ensure it is greater or equal to maxAutoRenewDuration specified in your azure function
You can update it from portal or service bus explorer
IMessageSession has CloseAsync and CompleteAsync methods.
If CloseAsync and CompleteAsync are not called (after acquiring a session and processing messages), what are the repercussions to the client and to azure service bus account?
The message is not successfully removed from the queue, the default maximum delivery count (retry) is 10. So your receiver can potentially receive the message 10 times, then it's put in deadletter queue (depending on the configuration) where it will stay for 14days (default setting)
For more details: https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dead-letter-queues
The approved answer is incorrect. TTL is applicable for the Active Queue, not for the Dead-letter Queue.
Secondly, the answer is implementation-specific, one not necessarily needs to use RegisterMessageHandler and can make use of MessageReceiver instead and something else.
Basically, CompleteAsync is used for deleting a locked message from the queue (can be DLQ as well) and CloseAsync is for closing the connection object.
I am using azure service bus topic and subscription mechanism and want to process the messages which are all in the dead letter queue.
Moreover i want to process the messages via azure web job in C# and send them back to queue. So i want to know how I can process the messages on the deadletter queue through my application?
When a message is deadlettered it goes onto the dead letter queue for the subscription from which it was read. You access that just like you'd access the original subscription except that you append /$DeadLetterQueue to the subscription name.
Moreover i want to process the messages via azure web job in C# and send them back to queue.
As spodger pointed that the path of your deadletter subscription would be:
{topic-path}/Subscriptions/{subcription-name}/$DeadLetterQueue
You could use the WebJobs SDK for Service Bus and leverage the ServiceBusTrigger to access your dead letter queue message(s) as follows:
public void ProcessDeadletterQueue(
[ServiceBusTrigger("topicName", "subscriptionName/$DeadLetterQueue")] BrokeredMessage message)
{
//TODO:
}
For more details, you could refer to here.
When a message is dead-lettered from a Service Bus Entity(Queue or Topic Subscription), it will be moved to the dead-letter path of the same entity. The reason for dead-lettering will be available in the message's custom properties DeadLetterReason and DeadLetterErrorDescription.
In order to receive the dead-letter messages,
string path = Microsoft.ServiceBus.Messaging.SubscriptionClient.FormatDeadLetterPath(topicPath, subscriptionName);
var subscriptionClient = SubscriptionClient.CreateFromConnectionString(connectionString, path);
BrokeredMessage message = subscriptionClient.Receive();
In a pervious project I have managed to setup a Alert rule that looks at poison queue message count and alerts using a webhook into slack when something is in the queue (once per day).
I was trying to find where this exists in Azure as it looks like things have moved around. If this is not a feature provided by azure could you give guidance on what's the best route in implementing something similar.
Thanks
I was trying to find where this exists in Azure as it looks like things have moved around. If this is not a feature provided by azure could you give guidance on what's the best route in implementing something similar.
As far as I know, currently there is no a feature provided by azure to send the a alert rule to check the poison queue count.
You need write you own logic to achieve this requirement.
I suggest you could considerusing webjob/azure function timer trigger or queue trigger.
If you want to check the poison count every 5 minutes(for example), you could choose timer trigger.
Then in the timer trigger method, you could use ApproximateMessageCount method to get the queue messages' count.
At last, you could use sendgrid to send the notification email to special account.
Codes:
//get the storage account from the connection string
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(CloudConfigurationManager.GetSetting("StorageConnectionString"));
//instantiate the client
CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();
CloudQueue q = queueClient.GetQueueReference("queue-poison");
q.FetchAttributes();
var qCnt = q.ApproximateMessageCount;
If you want to get the count when the new queue message has added into the poison queue. You could choose queue trigger. The codes is as same as the timer trigger, just change the parameters.