3

我一直在阅读2013 年 4 月引入的事件驱动消息编程模型、 OnMessageOptions.ExceptionReceived事件、内置RetryPolicy（2013 年 5 月，RetryPolicy.Default）、过时的瞬态故障处理应用程序块（2011） ，等等（见底部）。

我一直在监视通过消息泵收到的异常是否存在暂时性错误，并且每天都会收到MessagingCommunicationExceptions。本文（更新时间：2014 年 9 月 16 日），推荐以下内容：

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

我的理解是，在 2.1 (2013) 版本之后，无需编写额外的代码来处理服务总线上的瞬态错误。除非我的前提是错误的，否则为什么我每天都会收到瞬变错误？是否应该忽略通过消息泵收到的异常？如果被忽略，我只能假设意外的异常也会被忽略。我当然不希望这种情况发生。

Microsoft.ServiceBus 的版本是 2.4.0.0

还感兴趣：将 Windows Azure 服务总线从 1.x 升级到 2.0 - 重试策略，为 Windows Azure 服务总线引入事件驱动的消息编程模型， Azure SDK 2.0 版本中的新增功能（2013 年 4 月），中的新增功能Service Bus 2.1 版本（2013 年 5 月），瞬态故障处理。

4

1 回答 1

5

在这里正式回答。简而言之，在重试尝试后会冒泡异常以进行监控。长篇：

您从 ExceptionHandler 回调中获得的瞬时异常意味着这些异常在重试尝试后会冒泡。您应该将其记录下来以用于监控目的。如果需要，请采取行动。例如，如果您的客户端失去网络连接，您应该预期大量的通信异常会通过处理程序流出。在这种情况下，您可能需要采取适当的措施来解决问题。所以“我应该忽略它们吗？”这个问题的答案。真的要看条件。- Serkant Karaca，微软

于 2014-11-19T19:14:08.120 回答