3

I have a duplex WCF service and client running on the same machine. The client is configured to have 15 second timeouts:

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

The client is handling faults like this:

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

If I kill my Service process, the client correctly gets a TimeoutException after 15 seconds:

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)

However, the channel is not faulted at this point. My fault handler doesn't end up getting called until about 5 minutes after I kill the Service process. I thought that a TimeoutException would fault the channel (see this answer), but somehow that doesn't appear to be the case. Is there any way I can force the channel to be faulted more quickly after the Service process is killed?

Community
  • 1
  • 1
Eric
  • 5,842
  • 7
  • 42
  • 71
  • By the way, turned out that the channel wasn't getting faulted when my Service was getting killed, because the Service launches an unrelated executable, and the channel is somehow kept open as long as that process is running. – Eric Nov 19 '12 at 16:28

2 Answers2

4

This question Duplex channel Faulted event does not rise on second connection attempt suggestions the Faulted event isn't always fired. And the WCF state flow diagram on MSDN confirms that possibility - http://msdn.microsoft.com/en-us/library/ms789041.aspx

There are many paths to the closed state that don't go through the faulted state. Most likely, when you time out, the Abort() method is being called and you transition from the open state to the closing state without going through the faulted state. Add some logging to check the state throughout execution. If you're trying to reopen the channel after timing out, that would explain why you end up in the faulted state 5 minutes later. To solve your bigger problems, move logic in the FaultedHandler elsewhere so it's executed when you reach the closed state through other paths.

Community
  • 1
  • 1
evanmcdonnal
  • 46,131
  • 16
  • 104
  • 115
0

I know the question is old. But I searched quite a lot and always ended up here. So I thought I'd post my findings here:

It depends which Timeout.

If you hit the SendTimeout or ReceiveTimeout of your binding (in my case NetTcpBinding), then yes, the channel will fault.

BUT, if you hit the OperationTimeout of your Service (in my case DuplexChannel) then you will just get a TimeoutException and the channel will NOT fault.

toATwork
  • 1,335
  • 16
  • 34