Azure Service Bus is a cloud messaging service in Microsoft Azure that enables independent applications or services to communicate and exchange data through messages stored in queues or topics. This facilitates scalable and reliable communication in distributed systems.
Service Bus contains two types of messaging entities queues, and topics.
Queue: Queues transmit the messages in FIFO (First In, First Out) message delivery. Each message in a Queue can be received by only one active receiver.
Topic: In contrast to the Queues, Topics may contain multiple Subscriptions, each Subscription resembles a Queue. Based on predefined Rules, the messages can be sent to different Subscriptions.
Dead letter: Service Bus Queues and Topic Subscriptions provide a Sub-Queue, called a Dead-letter Queue (DLQ). Messages that cannot reach their intended destination for a variety of reasons will be held in a Dead-letter Queue.
A few reasons as to why the messages move to Dead-letter Queue are,
- HeaderSizeExceeded
- TTLExpiredException
- Session id is null
- MaxTransferHopCountExceeded
- Specified by application
In this blog, we show how Turbo360 provides an immaculate solution to resubmit and delete Service Bus dead letter queue messages.
How to handle messages in Azure Service Bus dead letter queue?
Turbo360 Business Application provides an immaculate solution using its Azure Service Bus Monitoring Tool to handle dead-letter messages. The Service Bus Queues or Topics can be associated with a Business Application will have an overview page of each resource with all the essential information about the resource.
Receive messages
The operations section of the resource in Turbo360 offers users four distinct choices, each providing the capability to access and manage Active messages and Dead Letter messages. The messages can be received in either of the two ways: peek-lock or defer.
Receiving the messages in peek-lock mode does not alter the state of the message. In contrast, once a message is retrieved in defer mode, its state is changed to deferred from active, making the messages unavailable for other receivers. The deferred messages can be retrieved separately in Turbo360.
Dead letter messages within Turbo360 can be fetched using several criteria, including the count of messages, sequence number, and the reason for the error. This offers us flexible options to access the required dead letter messages precisely.
Once the messages are retrieved, we will be provided with options like
- View the message properties and content.
- Resubmit the message.
- Repair and resubmit the message.
- Delete the message.
- View the error details of the message.
View message
We can view message details, including the message text, custom properties, and error information in Turbo360.
Resubmit
We can resubmit messages to a Queue or Topic as per our preference. Additionally, messages can also be directed for resubmission to an API endpoint. Turbo360 can back up the dead letter messages to a blob for more control and safety before initiating the resubmission process.
Repair and resubmit
Let us consider a scenario where the message is dead-lettered because of an error with the message content or properties. Simply attempting to resubmit these messages as they are will likely result in another failure. To tackle such scenarios, Serverlss360 provides an option called repair and resubmit the messages. This functionality allows us to edit the message content and modify its system and user-defined properties. The message can also be backed up to a blob before resubmitting.
Delete
Removing old or previously processed messages from the dead letter queue is essential to prevent the cycle of repeatedly resubmitting the same messages. Turbo360 simplifies this process by enabling the purging of messages from the dead letter queue once they have been resubmitted. To ensure the messages are not lost, they can be securely backed up to a blob before the purging.
How to automate resubmit and delete messages in the Service Bus dead letter queue?
Turbo360 provides an out-of-the-box solution called automated tasks. These tasks operate seamlessly in the background, following the provided configuration, all without requiring manual intervention.
Using these automated tasks, we can define various configurations to send messages to a queue, resubmit or repair and resubmit the dead letter messages to a specific destination, and purge the dead letter messages. Furthermore, we can set up a scheduling mechanism for the automated task, ensuring its execution consistently.
Filter messages: The automated tasks have an option called filters. We can configure specific criteria within these filters to determine which messages should be resubmitted or deleted. We will be presented with various choices, such as dead letter reason, system properties, and user properties. Using these criteria, the Turbo360 will sift through messages, identifying those that match the defined parameters and resubmitting them accordingly.
Repair messages: The automated task allows us to repair and resubmit the messages. This capability allows you to specify modifications to the message’s user properties before initiating the resubmission. You can add, edit, or remove properties based on your requirements before resubmitting the messages.
Conclusion
In conclusion, we now have a secure solution to manage Dead-Letter messages in both Queues and Topic Subscriptions effectively. Turbo360 offers an enhanced approach to resubmitting and deleting messages.
Elevate your Azure Service Bus capabilities by harnessing powerful toolsets and actionable insights from Turbo360. This enables streamlined troubleshooting of messaging concerns, ensuring a robust messaging environment.
