Azure Service Bus:通过带有内置重试策略的消息泵收到的瞬态错误(例外).为什么?

max*_*oin 3 queue message-queue azure azureservicebus retrypolicy

我一直在阅读2013年4月推出的事件驱动消息编程模型,OnMessageOptions.ExceptionReceived 事件,内置RetryPolicy(2013年5月,RetryPolicy.Default),瞬态故障处理应用程序块(2011)已过时等等(见下).

我一直在监视通过消息泵收到的异常错误,我每天都会收到MessagingCommunicationExceptions.此文章(更新日期:2014年9月16日),提出以下建议:

此异常表示当无法成功建立从消息传递客户端到Service Bus基础结构的连接时可能出现的通信错误.在大多数情况下,如果存在网络连接,则可以将此错误视为瞬态错误.客户端可以尝试重试导致此类异常的操作.还建议您验证域名解析服务(DNS)是否可操作,因为此错误可能表示无法解析目标主机名.

我的理解是,在版本2.1(2013)之后,没有额外的代码可用于处理服务总线上的瞬态错误.除非我的前提是错误的,为什么我每天都会收到瞬态错误?是否应忽略通过消息泵收到的异常?如果忽略,我只能假设意外的异常也会被忽略..我当然不希望这种情况发生.

Microsoft.ServiceBus的版本是2.4.0.0

同样感兴趣:从1.x的升级Windows Azure的服务总线2.0 -重试政策,介绍了Windows Azure的服务总线事件驱动的消息编程模型,是什么在Azure的SDK 2.0版本(2013年4月)的新功能,什么是新Service Bus 2.1版本(2013年5月),瞬态故障处理.

max*_*oin 5

在这里正式回答.简而言之,在重试尝试之后,会出现异常以进行监视.长期:

从ExceptionHandler回调中获得的瞬态异常意味着在重试尝试后会出现这些异常.您应该记录它以进行监视.如果需要,请采取行动.例如,如果您的客户端失去网络连接,您应该会通过处理程序出现大量通信异常.在这种情况下,您可能需要采取适当的措施来解决问题.所以回答问题"我应该忽略它们吗?" 真的取决于条件. - 微软Serkant Karaca