如何解决WCF中的PipeExceptions和CommunicationExceptions？

Question

我有一个由几个WCF服务组成的应用程序,其中一些服务在Workflow Foundation(.NET 3.5)中实现,其他服务只是简单的C#.出于性能原因,这些服务通过netNamedPipeBinding相互通信.麻烦的是,一旦系统负载增加,我就会看到越来越多的CommunicationExceptions和底层的PipeExceptions.有趣的是,这些交易似乎最终完成.其中一个原因是我们在工作流中有一个重试机制,但即使我在WCF跟踪中看到这些错误,即使来自普通C#服务的调用也会成功.在Windows的命名管道子系统中有什么重试机制吗？

但是,我希望修复这些错误,或者至少了解潜在的问题.我觉得它们正在影响应用程序的性能和稳定性.如果我没有看到来自服务本身的任何其他异常,我该如何正确地诊断和诊断这些错误的根本原因？

以下是我得到的一些例外情况:

PipeException: 从管道读取错误:管道已结束.(109,0x6d).

和:

PipeException: 由于管道已关闭,因此无法完成操作.这可能是由管道另一端的应用程序引起的.

在TimeoutException中: 管道连接已中止,因为管道的异步读取未在分配的超时00:02:00内完成.分配给此操作的时间可能是较长超时的一部分.

现在超时异常似乎来自系统处理负载的问题.这些操作通常很小,但它们的数量似乎是问题所在.或者这可能是先前管道连接的结果被终止而没有返回池中？

我已尝试在WCF配置中尝试使用serviceThrottling行为来增加实例数等,但这些错误不断涌现.有小费吗？

/编辑:我确实打开了WCF跟踪和消息记录.这就是我看到PipeExceptions和CommunicationExceptions的地方.应用程序本身没有显示任何错误.我们已经对WCF服务进行了相当多的检测,以便使用log4net记录所有异常,并且我根本看不到这些日志中的任何错误.这一切似乎都发生在WCF级别.

Answer 1

您可能想要激活服务上的日志记录和活动跟踪。然后使用服务跟踪查看器可以清楚地了解事件的顺序。

这将提供大量数据需要处理，因此我建议您仅针对一个测试用例激活它，然后停用它。这应该限制数据量。