我有一个双工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;
如果我终止了我的服务过程,则客户端在15秒后正确获得TimeoutException
:
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分钟后,我的错误处理程序才被调用。我以为TimeoutException
会导致通道故障(请参见此answer),但似乎并非如此。服务进程被终止后,有什么方法可以迫使我更快地对通道进行故障处理?
此问题Duplex channel Faulted event does not rise on second connection attempt建议Faulted
事件并非总是触发。并且MSDN上的WCF状态流程图证实了这种可能性-http://msdn.microsoft.com/en-us/library/ms789041.aspx
有许多通往关闭状态的路径不会经过故障状态。最有可能的是,当您超时时,将调用Abort()
方法,并且您会从打开状态转换为关闭状态,而不会经历故障状态。添加一些日志记录以检查整个执行过程中的状态。如果您尝试在超时后重新打开频道,那将解释为什么5分钟后您最终处于故障状态。为了解决更大的问题,请将逻辑移至FaultedHandler
的其他位置,以便在您通过其他路径达到关闭状态时执行该逻辑。
我知道这个问题很旧。但是我搜索了很多东西,并且总是在这里结束。所以我想把发现发表在这里:
取决于哪个超时。
如果您击中绑定的SendTimeout
或ReceiveTimeout
(在我的情况下为NetTcpBinding
,则是的,通道将发生故障。
但是,如果您按下了服务的OperationTimeout
(在我的情况下是DuplexChannel),那么您只会得到TimeoutException
,并且该频道将NOT出故障。