我的设置详情

我在我的WCF“服务器”中使用NetNamedPipeBinding，它是作为Windows服务运行的应用程序的一部分。

我有两个客户端使用DuplexChannelFactory创建的通道与WCF服务器通信。一个是ASP.Net MVC 3 Web应用程序，它使用每个页面请求创建一个通道（然后将其关闭**）。另一个是WPF应用程序（用作服务的一种监视控制台/诊断工具）。

一切都运行良好 - 通常持续一周或更长时间 - 很多人访问Web应用程序，但偶尔会在WCF“服务器”内部出现问题并且客户端开始报告异常“通信对象，System.ServiceModel .Channels.ServiceChannel，不能用于通信，因为它“无论何时尝试创建频道代理都处于故障状态。”

一旦服务器“出现故障”，每次连接尝试都会导致该错误。甚至控制台应用程序的新实例也会报告它。这让我相信这不是“客户”端的问题。

**注意：我认为频道因每个页面请求而关闭。它被实例化为MVC控制器的成员，据我所知，它不属于范围并且在请求结束时处理。也许我错了？

问题：

有没有人对我在哪里寻找建议 - 甚至我在测试环境中如何重现这个问题。

这种事可以完全消除吗？或者我应该在“服务器”中使用一个线程，该线程每隔几分钟就会尝试连接到命名管道服务，如果失败则重启服务？

附加信息

包含我正在使用的代码（在WCF“服务器”中）来监听命名管道上的请求可能会有所帮助

host = new ServiceHost(
    this,
    new Uri[] {
        new Uri("net.pipe://localhost")
    }
);
host.AddServiceEndpoint(
    typeof(IStationDirectory),
    new NetNamedPipeBinding(),
    "StationDirectory"
);

host.Open();

/* Some logging code here */


Thread.Sleep(Timeout.Infinite);

决议更新（2013）

我知道自从我提出这个问题以来已经很长时间了 - 但我刚刚在这里看到了这个问题，而且我认为我应该补充说尼克已经击中了头部。我相信这是导致问题的消息有效负载大小。消息中包含“报告”对象列表，每个对象都链接到上一个报告。随着时间的推移，这个列修剪旧报告并将WCF消息保持在或多或少的固定大小可以阻止故障。在过去的几年里，该应用程序运行非常可靠。

Answer 1

我首先做一些WCF跟踪。

http://msdn.microsoft.com/en-us/library/ms733025.aspx

如果他们发生错误，绝对没有任何事件记录在你可以看到的任何事件（在事件查看器中）那么它可能是

邮件有效内容对于您的绑定来说太大了。如果你要返回大的结果集，而且它是断断续续的，我会从这里开始。检查你的maxItemsInObjectGraph绑定配置。
服务启动时未处理的异常。这似乎不是你的问题。

什么可能导致WCF NamedPipe频道出现故障（在服务器端？）

我的设置详情

问题：

附加信息

更多问题

决议更新（2013）

1 个答案: