views:

699

answers:

2

My WCF service uses netTcpBinding, and has a callback object.

I need to service multiple concurrent clients, and mantain sessions, so the service is decorated with [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession, ConcurrencyMode = ConcurrencyMode.Multiple]

To avoid thread deadlocks, the callback class is decorated with [CallbackBehavior(UseSynchronizationContext=false)] and I use SynchronizationContext to execute the method in the UI thread.

The problem is that sometimes the channel gest closed with no reason (ICommunicationObject.Closing event gets fired). After that, I get exceptions in any subsequent service call.

Looking in the trace file, the last message is a callback call, however, the callback method never gets invoked. There are no exceptions.

After some debugging I identified that this happens only when the callback call is made in the middle of a synchronous operation. The steps would be this: 1- Call to service method A with IsOneWay=true 2- Call to service method B with IsOneWay=false 3- A invokes a callback method, but B is still executing.

This shouldn't be a problem because the callback has UseSynchronizationContext=false, so the callback call could be attended in a separate thread.

I was unable to reproduce the problem in a simpler scenario. Following these steps in a simple project executes successfully.

Any idea of what could be happening or how to identify the problem?

+2  A: 

I think what's probably happening is the client is faulting the channel because it received the callback message when it was expecting the reply message. In WCF with net.tcp, callbacks and replies use the same channel.

As a rule, you should never call a callback method inside the body of a IsOneWay=false OperationContract method. The safest thing would be to not have any IsOneWay=true methods in your contract whatsoever, but you can safely have them just so long as they don't call into the callback contract.

alexdej
A: 

Thanks for the response! I could solve the error.

It was a serialization problem, I added "IncludeExceptionsInFaults = true" in the service and callback behavior attribute, and then I was able to see the error. The problem was that I was sending a DataTable with columns of type object.

Juan