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();
Related
I want to have the following logic for Service Bus queue:
only one message in queue (storing datetime)
if we try to add new message never than added to queue - reject it
Is it possible?
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.
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.
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.
When using the WebJobs SDK what is the proper way to move a BrokeredMessage to the deadletter queue? Usually I would just call msg.DeadLetter(). However, the SDK takes care of managing the life cycle of the brokered message. It will call msg.Complete() if the method returns successful, and it will retry the message if an exception occurs. I need the 3rd case of telling the ServiceBus queue to move the message to the deadletter queue as it is a bad message.
You can explicitly deadletter the service bus queue and trigger a function when the message is dead lettered.
public static void ProcessSBQueueMessage(
[ServiceBusTrigger("inputqueue")] BrokeredMessage inputText)
{
inputText.DeadLetter("Webjobs", "webjobsdescription");
Console.WriteLine(inputText);
}
public static void ProcessSBDeadLetterQueueMessage(
[ServiceBusTrigger("inputqueue/$DeadLetterQueue")] BrokeredMessage inputText)
{
Console.WriteLine(inputText);
}