我有一个由多个 WCF 服务组成的应用程序，其中一些是在 Workflow Foundation (.NET 3.5) 中实现的，其他只是简单的 C# 实现。出于性能原因，这些服务通过 netNamedPipeBinding 相互通信。问题是，一旦系统负载增加，我就会看到越来越多的 CommunicationException 和底层 PipeException。有趣的是，这些交易似乎最终还是完成了。原因之一是我们在工作流中具有重试机制，但即使是来自普通 C# 服务的调用也会成功，即使我在 WCF 跟踪中看到这些错误。 Windows 的命名管道子系统中是否有某种重试机制？
但是我希望修复这些错误，或者至少了解根本问题。我觉得它们正在影响应用程序的性能和稳定性。如果我没有看到来自服务本身的任何其他异常，我该如何正确诊断这些错误的根本原因？
以下是我遇到的一些异常(exception)情况:
PipeException: 从管道读取错误:管道已结束。 (109，0x6d)。
还有:
PipeException: 由于管道已关闭，操作无法完成。这可能是由于管道另一端的应用程序退出造成的。
在 TimeoutException 内: 管道连接被中止，因为管道的异步读取未在分配的超时 00:02:00 内完成。分配给此操作的时间可能是较长超时的一部分。
现在超时异常似乎是由于系统在处理负载时遇到问题所致。这些操作通常很小，但它们的数量似乎是问题所在。或者这可能是先前管道连接被终止并且没有返回到池的结果？
我尝试在 WCF 配置中尝试使用 serviceThrotdling 行为来增加实例数量等，但这些错误不断出现。有什么建议吗？
/编辑:我确实打开了 WCF 跟踪和消息日志记录。这就是我看到 PipeExceptions 和 CommunicationExceptions 的地方。应用程序本身没有显示任何错误。我们对 WCF 服务进行了相当多的检测，以便使用 log4net 记录所有异常，并且我在这些日志中根本没有看到任何错误。这一切似乎都发生在 WCF 级别。
最佳答案
您可能希望在您的服务上激活日志记录和事件跟踪。然后使用服务跟踪查看器可以清楚地了解事件的顺序。
这将提供大量数据需要处理，因此我建议您仅针对一个测试用例激活它，然后停用它。这应该会限制数据量。
关于.net-3.5 - 如何解决 WCF 中的 PipeException 和 CommunicationException 问题？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3733951/