views:

43

answers:

4

I'm working on shipping in a change for my lab that will hopefully help diagnose some weird channel-faulting weirdness we're seeing. There's a test application that uses DuplexChannelFactory to connect to a couple windows services, and for some reason the channels on this test application seem to be faulting quite a bit. I have plans to implement some retry logic in there, but it would be great to figure out why exactly they're faulting.

I know that channel factories and proxy objects all implement a lot of interfaces, and I've used reflector to crawl through some of them, but I haven't found anything like what I'm looking for. Is there a way to query these objects after they've faulted in order to get some information about what caused the fault?

Edit: The configuration is very basic--the binding is just the default-constructed NetTcpBinding, the service implementation has [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Reentrant)], and no special attributes are on any of the operations in the service contract. However, I'm asking more about general techniques in diagnosing channel faults, not diagnosing this specific case. I wouldn't expect configuration specifics to have too much impact on that; if anything, the configuration details would be something returned by said diagnostics, right?

+2  A: 

First thing is it this test application, or are the specific services used by other clients.

Assuming that it is the test client that is causing the problem. There could be 2 problems:

  • Not closing proxies, therefore hitting max connections to the server.
  • Not aborting proxies when they are in a failed state.
Shiraz Bhaiji
Most likely cause of a faulted channel is a server-side exception.
Aliostad
+1  A: 

Diagnostic tool you are looking for is called WCF Tracing. It usually shows why the channel has faulted. You can configure it on both client and server and use SvcTraceViewer.exe to browse collected traces.

Ladislav Mrnka
1+ I wanted to mention it.
Aliostad
+1  A: 

Ladislav and Shiraz answers are all good and I have gave them +1.

All I can add to them is that normally a faulted channel is the result of unhandled exception on the server. When that happens, WCF thinks that there is somethig fundamentally wrong with the server and faults the channel so that it cannot be used.

The correct approach - which I believe should have been default and come for free - is for the service to catch the exception and create a FaultException and return it (look at this form example http://www.c-sharpcorner.com/UploadFile/ankithakur/ExceptionHandlingWCF12282007072617AM/ExceptionHandlingWCF.aspx)

The reason WCF does not make as default is that it changes the contract and the WSDL so the client has to get the updated WSDL.

So if I were you, I would catch the exceptions, log them and then return a fault exception and this way I would know what the problem is and channels are not faulted.

Aliostad
A: 

Have you hooked on to the ICommunicationObject.OnFauled

Sajay
I have, but for the life of me I could swear it doesn't do anything. Even when the channel is intentionally faulted server-side, nothing happens on the client. Doesn't seem very useful. I'm assuming there's some configuration detail I'm missing to make it work or something.
bwerks