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

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

i've been reading on event-driven message programming model introduced in apr 2013, onmessageoptions.exceptionreceived event, built-in retrypolicy (may 2013, retrypolicy.default), the transient fault handling application block (2011) outdated, , more (see bottom).

i've been monitoring exceptions received through message pump transient errors , daily messagingcommunicationexceptions. article (updated: september 16, 2014), recommend next :

this exception signals communication error can manifest when connection messaging client service bus infrastructure cannot established. in cases, provided network connectivity exists, error can treated transient. client can effort retry operation has resulted in type of exception. recommended verify whether domain name resolution service (dns) operational error may indicate target host name cannot resolved.

my understanding there no code write handle transients errors on service bus after version 2.1 (2013). unless premise wrong, why receiving transients errors each , every day? should exceptions received through message pump ignored? if ignored, can assume unexpected exceptions ignored.. , don't want happen of course.

version of microsoft.servicebus 2.4.0.0

also of involvement : upgrading windows azure service bus 1.x 2.0 - retry policy, introducing event-driven message programming model windows azure service bus, what's new in azure sdk 2.0 release (april 2013), what's new in service bus 2.1 release (may 2013), transient fault handling.

officially answered here. in short, exceptions bubbled monitoring purpose after retry attempts. in long:

the transient exceptions exceptionhandler callback means exceptions bubled after retry attempts. should log monitoring purposes. take action if need to. eample, if client loses network connectivity should expect big number of communication exceptions bleeding through handler. in such cases may need take proper actions prepare things. reply question "should ignore them?" depends on conditions. - serkant karaca, microsoft

azure queue message-queue azureservicebus retrypolicy