Consider an E-Commerce Application with millions of users, built with various microservices. Since these microservices are decoupled, highly scalable, the communication and data sharing should be more reliable and seamless for business continuity. Here comes the Enterprise Service Bus technology. An enterprise service bus implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA). There are various ESB solutions available in the Market, but What service is the more reliable solution at scale for Enterprises?
Yes, it is Azure Service Bus, an ESB Service offered by Microsoft Azure. Enterprises widely use Azure Service Bus for reliable message handling in their business applications. There are few Exceptions that every Service Bus user should be aware of in the day-to-day operations and support tasks. In this article, we have decoded all the exceptions in Azure Service Bus to meet Operational Efficiency.
Azure Service Bus Exceptions
Azure Service Bus queues and topic subscriptions provide a secondary sub-queue, called a dead-letter queue (DLQ). The dead-letter queue does not need to be explicitly created and cannot be deleted or managed independent of the primary entity. The purpose of a dead-letter queue is to hold messages that do not get delivered to the receiver due to various exceptions. Below is the list of exceptions that makes a Service Bus message to get dead-lettered in a queue:
- HeaderSizeExceeded – The size quota for this stream gets exceeded.
- TTLExpiredException – The message expired and was dead lettered. See the time to live section for details.
- Session ID is null – Session enabled entity doesn’t allow a message whose session identifier is null.
- MaxTransferHopCountExceeded – The maximum number of allowed hops when forwarding between queues. The value set to 4.
- MaxDeliveryCountExceededExceptionMessage – Message couldn’t be consumed after maximum delivery attempts.
- FilterException – These are the Invalid Filter rules in Azure Service Bus Topic Subscription.
Apart from the above listed dead-letter reasons, the user can even provide a custom dead-letter reason for exceptions and manually dead-letter a message using Service Bus SDKs.
Strengthen your Azure Service Bus monitoring, and get powerful toolsets and actionable insights to troubleshoot messaging issues with the help of Turbo360.
Azure Service Bus Exception Handling
Using Azure Service Bus dead-lettering, we can capture and understand the cause of the actual problem and the description. As a support user, the need would be to solve these exceptions using tools offered by Azure Service Bus.
Below is the list of tools used to handle exceptions in Azure Service Bus for Operations and Support excellence:
- Metrics
- Sessions
- Filters
- Operational tools
Metrics
Before handling the exceptions, the first and foremost need would be to monitor the exceptions in real-time. Here comes the Azure Metrics to monitor dead-letter messages. Azure Metrics are the most used azure service to perform monitoring and analytics on Azure Serverless Integrations. Apart from monitoring Dead-letter messages, it is also possible to monitor other unnoticed metrics that are listed below:
- ActiveMessages – Count of Active messages in a queue/topic over a specified period
- Dead-lettered messages – Count of dead-lettered messages in a queue/topic over a specified period
- Server Errors – The number of requests not processed because of an error in the Service Bus service over a specified period
- User Errors – The number of requests not processed because of user errors over a specified period. These metrics consist of Client-side errors (In HTTP, that would be 400 errors) as well as Errors that occur while processing messages, such as MessageLockLostException
- Throttled Requests – The number of requests that get throttled because the usage gets exceeded
- Incoming Messages/Outgoing Messages – The number of events or messages sent/received to Service Bus over a specified period
To know more about the Aggregation type and Unit of the above metrics
Sessions
Consider when the Service Bus messages got “Session ID is null“. This exception will happen when the user has a session enable Queue or Topic but failed to provide Session-Id while sending the message. First, let us under what is Service Bus Sessions.
Azure Service Bus sessions offer combined and ordered handling of unbounded sequences of related messages, i.e., it provides a way to group a set of related messages. It also provides concurrent de-multiplexing of interleaved message streams while preserving and guaranteeing ordered delivery. User can enable Sessions in Azure Service Bus while creating a Service Bus queue or topic. Any application or client sending messages to a Service Bus Queue or Topic can create a session by setting the ‘SessionId’ property to any value which uniquely identifies that session. User can solve the above exception by providing the SessionId and Reprocess the message back to the Active Queue or Topic using Service Bus SDKs. It is also possible to add SessionId for a dead-letter message using Turbo360 Message Processing.
To know more about Sessions and SDKs:
Filters
Azure Service Bus offers topics that work in the Publisher/Subscriber Model. There will be multiple subscribers for a single topic. Subscribers can define which messages they want to receive from a topic. These messages get specified in the form of one or more named subscription rules. Each rule consists of a filter condition that selects messages and optionally contains an action that annotates the selected message. Here comes the FilterException; the messages will get dead-lettered with this exception when there is an invalid filter in Topic Subscription. User can handle this exception by creating valid filters based on available types of filters like Correlation Filter, SQL Filter and Boolean filters. It can be done through the Azure Portal itself, as given below:
-
- Go to Appropriate Namespace -> Topic -> Subscription
- In the Overview menu, click on the appropriate filter under the Filters section
- Update the existing filter and click Save changes
To know more about Filters in Azure Service Bus:
- Auto Filter Messages into Subscriptions in Azure Service Bus Topic
- Manage Azure Topic Subscription Rules
Operational Tools
Consider when there are exceptions like MaxTransferHopCountExceeded and MaxDeliveryCountExceededExceptionMessage, it is possible to handle these exceptions with the help of various operational tools available in the Service bus. MaxTransferHopCountExceeded exception would happen when the same message transferred to 4 different hops. This exception would occur through Auto – Forwarding enabled in a queue or topic subscription in a typical scenario. To handle this exception, the user can revisit the auto-forwarding configuration of the available queue and make the changes accordingly. But if your need is to forward to multiple queues, Here comes the Automated Task in Turbo360. This Automated Task will process all the messages from one queue to another queue on a regular interval without configuring Auto-Forwarding. In the below section, we will discuss more Automated Task in Turbo360.
Consider in the case of MaxDeliveryCountExceededExceptionMessage, and this exception would happen when the messages don’t get consumed after maximum delivery attempts. The full delivery count gets configured based on the need of the user. By default, it gets configured to 20. Below are the instructions to configure Max delivery count for a Service Bus.
-
- Go to Appropriate Namespace -> Queue/Topic Subscription
- In the Overview menu, Click change on Max Delivery count property
- Select the required value in the Max Delivery count dialogue box
- Click OK to save the changes.
Increased Operational Excellence with Turbo360
For most of the exceptions, there is a way to handle those exceptions using Native Azure Service Bus tools. But Consider when there are exceptions like HeaderSizeExceeded and TTLExpired, the user would need some operational capabilities like altering the message content and reprocessing the message to the backup queue.
For HeaderSizeExceeded, the user should have a maximum of 64Kb, including both System and Custom Properties. User can handle this exception by changing or deleting a few custom property of a message. Here comes Turbo360 Message processing.
Using Service Bus Message processing, the user can perform reprocessing on Service Bus dead-letter messages. User can customize, add or delete the custom properties based on the need and Maximum size. Turbo360 is the only tool in the Market that provides dead-letter management and message processing for Azure Service Bus queues and team.
Consider when there is TTLExpired; this exception would happen when the downstream application failed to process the message. Since there is a Time to Live constrain in place, the message will automatically get dead-lettered when it reaches the time. The user can solve this exception with the help of Automated Task in Turbo360.
An Automated Task is a background process that will run based on the pre-set configuration. Using Automated Tasks, user can perform message processing like Resubmit, Resubmit & Delete and Send Messages to a Service Bus queue or topic along with the Dead-letter reason like TTExpired or other Custom reason. Automate day-to-day messaging operations by scheduling the Automated Task. The user can now focus on other highly valued tasks.
Check out the blog on Azure Service Bus delete message to understand how to resubmit and delete messages in Azure Service Bus Messaging.
Wrap up
In this article, we saw the various exceptions that would occur in Azure Service Bus and how to solve those exceptions using Native tools offered by Azure to improve Operational Excellence. We also discussed how Turbo360 supports Azure Service Bus as a complementary tool by offering various operational and support related tools to manage Azure Service Bus better.
