Azure Service Bus: transient errors (exceptions) received through the message pump with built-in retry policy. Why?

3
votes

I've been reading on the Event-Driven Message Programming Model introduced in April 2013, the OnMessageOptions.ExceptionReceived Event, the built-in RetryPolicy (May 2013, RetryPolicy.Default), The Transient Fault Handling Application Block (2011) which is outdated, and more (see bottom).

I've been monitoring the exceptions received through the message pump for transient errors and I get daily MessagingCommunicationExceptions. This article (Updated: September 16, 2014), recommend the following :

This exception signals a communication error that can manifest itself when a connection from the messaging client to the Service Bus infrastructure cannot be successfully established. In most cases, provided network connectivity exists, this error can be treated as transient. The client can attempt to retry the operation that has resulted in this type of exception. It is also recommended that you verify whether the domain name resolution service (DNS) is operational as this error may indicate that the target host name cannot be resolved.

My understanding is that there is no extra code to write to handle transients errors on the Service Bus after version 2.1 (2013). Unless my premise is wrong, why am I receiving transients errors each and every day? Should exceptions received through the message pump be ignored? If ignored, I can only assume that unexpected exceptions will also be ignored.. and I don't want that to happen of course.

Version of Microsoft.ServiceBus is 2.4.0.0

Also of interest : upgrading Windows Azure Service Bus from 1.x to 2.0 - Retry Policy, Introducing the Event-Driven Message Programming Model for the Windows Azure Service Bus, What's New in the Azure SDK 2.0 Release (April 2013), What's New in the Service Bus 2.1 Release (May 2013), Transient Fault Handling.

1
azurequeuemessage-queueazureservicebusretrypolicy

1 Answers

5
votes

Officially answered here. In short, exceptions are bubbled for monitoring purpose after retry attempts. In long:

The transient exceptions you get from ExceptionHandler callback means those exceptions are bubled up after retry attempts. You should just log it for monitoring purposes. Take action if you need to. For eample, if your client loses network connectivity you should expect large number of communication exceptions bleeding through the handler. In such cases you may need to take proper actions to fix things. So the answer to question "should I ignore them?" really depends on conditions. - Serkant Karaca, Microsoft