3

我有一个双工 WCF 服务和客户端在同一台机器上运行。客户端配置为 15 秒超时：

<binding name="NetTcpBinding_IServiceIPC" closeTimeout="00:00:15"
      openTimeout="00:00:15" receiveTimeout="00:00:15" sendTimeout="00:00:15" />

客户端正在处理这样的错误：

client.InnerChannel.Faulted += FaultHandler;
client.InnerDuplexChannel.Faulted += FaultHandler;
client.ChannelFactory.Faulted += FaultHandler;

TimeoutException如果我终止我的服务进程，客户端会在 15 秒后正确获得：

This request operation sent to net.tcp://localhost:8732/Service/ did not receive a reply within the configured timeout (00:00:15).  The time allotted to this operation may have been a portion of a longer timeout.  This may be because the service is still processing the operation or because the service was unable to send a reply message.  Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client. (System.TimeoutException)

但是，此时通道没有故障。我的故障处理程序直到我终止服务进程后大约 5 分钟才被调用。我认为 aTimeoutException会使频道出错（请参阅此答案），但不知何故，情况似乎并非如此。有什么方法可以在服务进程被杀死后强制通道更快地出现故障？

4

2 回答 2

4

这个问题Duplex channel Faulted event does not raise on second connection attempt建议该Faulted事件并不总是被触发。MSDN 上的 WCF 状态流程图证实了这种可能性 - http://msdn.microsoft.com/en-us/library/ms789041.aspx

有许多通往关闭状态的路径不会经过故障状态。最有可能的是，当您超时时，Abort()正在调用该方法并且您从打开状态转换到关闭状态，而无需经历故障状态。添加一些日志记录以检查整个执行过程中的状态。如果您在超时后尝试重新打开频道，这可以解释为什么您会在 5 分钟后进入故障状态。要解决更大的问题，请将逻辑移至FaultedHandler其他位置，以便在通过其他路径达到关闭状态时执行。

于 2012-11-15T18:48:43.293 回答
0

我知道这个问题很老了。但我搜索了很多，总是在这里结束。所以我想我会在这里发布我的发现：

这取决于哪个超时。

如果您点击SendTimeout或ReceiveTimeout您的绑定（在我的情况下NetTcpBinding），那么是的，通道将出现故障。

但是，如果你点击OperationTimeout你的服务（在我的情况下是 DuplexChannel），那么你只会得到一个TimeoutException并且通道不会出错。

于 2020-02-24T08:48:24.903 回答