神秘 => 从管道读取错误：管道已结束。 (109, 0x6d)

Posted 2023-02-16

【中文标题】神秘 => 从管道读取错误：管道已结束。 (109, 0x6d)

【英文标题】：Mysterious => There was an error reading from the pipe: The pipe has been ended. (109, 0x6d)

【发布时间】：2016-08-03 09:13:00

【问题描述】：

我知道这里有数百万个关于这个例外的帖子，但我不明白这里的这个。 我有一个非常简单的示例管道服务：

[ServiceContract]
public interface ISRARiskExport
 
[OperationContract(IsOneWay = true)]
void RiskExport(long sraid, long revID, string JobID);

当我调用它时，一切都很好，但是当两个客户端同时调用它时，它会抛出这个异常。 服务器直接设置一个新线程并返回给客户端。

public void RiskExport(long sraid, long revID, string JobID)

ThreadStarter starter = new ThreadStarter(new ThreadStartWithParameter(RunExportJob), new SRAInfo()  sraid = sraid, revID = revID, JobID = JobID );
Thread t = new Thread(new System.Threading.ThreadStart(starter.ThreadStartEntry));
t.IsBackground = true;
t.Start();

因此，这不可能是超时问题，因为从客户端到服务器再返回需要不到 1 秒的时间。特别是当我从单元测试中在 for 循环中同步调用它时

string JobID = "";
for (int i = 0; i < 100; i++)

string baseAddress = "net.pipe://localhost/SRADocumentService";
ChannelFactory<ISRARiskExport> factory = new ChannelFactory<ISRARiskExport>(new NetNamedPipeBinding(NetNamedPipeSecurityMode.None), new EndpointAddress(baseAddress));
ISRARiskExport svc = factory.CreateChannel();
JobID = Guid.NewGuid().ToString();
svc.RiskExport(sraid, revID, JobID);

我已经准备好激活 WCF 跟踪。在这里，我可以看到每次调用都会引发异常。详细信息窗格根本没有帮助我，因为它向我显示了两次异常 => 从管道读取错误：管道已结束。 (109, 0x6d)。

使用不同的堆栈跟踪 =>

我还在 Debugview 中看到异常在调用返回客户端很久之后才出现。 我的问题是：

为什么服务在抛出此异常时仍按预期工作

我怎样才能摆脱异常，因为它们都进入了日志文件，而我无法捕捉它。

感谢迈克尔

【问题讨论】：

没有这个例子没有人可以帮助你。您可能想要编辑帖子。

哈哈 - 我无法添加所有内容。所以我分步进行。

【参考方案1】：

我得到了具有非常相似跟踪数据的相同序列异常，并且在将绑定更改为以下异常后，异常停止了。请注意，我不知道这些更改的含义是什么，因此请谨慎使用。

    public Binding GetBinding()
    
        var binding = new NetNamedPipeBinding
        
            OpenTimeout = TimeSpan.FromMinutes(15),
            SendTimeout = TimeSpan.FromMinutes(15),
            CloseTimeout = TimeSpan.FromMinutes(15),
            MaxConnections = 200,
            MaxBufferSize = int.MaxValue,
            MaxReceivedMessageSize = int.MaxValue,
            MaxBufferPoolSize = int.MaxValue,
            TransactionFlow = false,
            TransactionProtocol = TransactionProtocol.WSAtomicTransaction11,
            TransferMode = TransferMode.StreamedRequest,
            HostNameComparisonMode = HostNameComparisonMode.WeakWildcard
        ;
        binding.Security.Transport.ProtectionLevel = ProtectionLevel.None;
        return binding;
    

【参考方案2】：

由于命名管道池是如何在 WCF 内部实现的，我们已经看到了这种行为。在我们的案例中，此类异常或多或少随机出现在日志中（不是在每次调用之后），但在研究了 MS 参考资料后，我们认为它们是不可避免的。而且您提到“在呼叫返回客户端很久之后出现异常”，这让我认为您正在观察相同的行为。

您可以看到 here 的“证明”：NamedPipeConnectionPoolSettings 将 IdleTimeout 设置为某个默认值，等于 2 minutes。

也许我们的决定是错误的，这是不可避免的，因为我现在看到 NamedPipeConnectionPoolSettings 类是公共的，IdleTimeout 属性也是公共的，可以设置为 TimeSpan.MaxValue，这应该可以防止关闭管道和这些异常.

希望这会有所帮助。