Vista - WCF deadlock timeout on reentrant callback to Windows App

I have this setup:
- Using WCF with net-tcp binding.
- Have a singleton service (implements IService) that I want to be able to
publish "events" (currently the data published is just a String) to all
subscribers.
- An ISubscriber callback contract has: string GetName(void) and void
AddMessage(String msg).
- An IService contract that specifies its callback contract is ISubscriber.
- IService has void Subscribe(void) method.
- Service.Subscribe() uses
OperationContext.Current.GetCallbackChannel<ISubscriber>() to get the
"calling" ISubscriber.
- In Service.Subscribe(), the code gets the name of the calling ISubscriber
using ISubscriber.GetName(). This deadlocks in one case.
- The Service class and the Subscriber class are both marked
ConcurrencyMode.Multiple (Reentrant also deadlocks).

The Service.Subscribe() callback to ISubscriber.GetName() deadlocks if the
client is calling Subscribe() from the main Windows App thread (from a button
click). When the client uses a separate temporary thread to call Subscribe
it doesn't deadlock, also from a Console application it doesn’t deadlock. So
evidently the callback is deadlocking relative to the windows app main thread.

What does the WCF callback have to do with the windows app main thread?

Thanks,
Ryan

Thus wrote Ryan,

> I have this setup:
> - Using WCF with net-tcp binding.
> - Have a singleton service (implements IService) that I want to be
> able to
> publish "events" (currently the data published is just a String) to
> all
> subscribers.
> - An ISubscriber callback contract has: string GetName(void) and void
> AddMessage(String msg).
> - An IService contract that specifies its callback contract is
> ISubscriber.
> - IService has void Subscribe(void) method.
> - Service.Subscribe() uses
> OperationContext.Current.GetCallbackChannel<ISubscriber>() to get the
> "calling" ISubscriber.
> - In Service.Subscribe(), the code gets the name of the calling
> ISubscriber
> using ISubscriber.GetName(). This deadlocks in one case.
> - The Service class and the Subscriber class are both marked
> ConcurrencyMode.Multiple (Reentrant also deadlocks).
> The Service.Subscribe() callback to ISubscriber.GetName() deadlocks if
> the client is calling Subscribe() from the main Windows App thread
> (from a button click). When the client uses a separate temporary
> thread to call Subscribe it doesn't deadlock, also from a Console
> application it doesn’t deadlock. So evidently the callback is
> deadlocking relative to the windows app main thread.
>
> What does the WCF callback have to do with the windows app main
> thread?

Since by default a WCF service uses [ServiceBehavior(UseSynchronizationContext
=true)], your callback gets marshalled back to the UI thread, becoming a
message dispatched to your Windows Form... and remains stuck there, because
your main UI thread is still busy waiting on Service.Subscribe() to complete.

Due to that marshalling behavior, the notion of your current ConcurrencyMode
can be highly misleading here. Actually, using anything else other than ConcurrencyMode.Single
can be rather dangerous in this particular scenario.

Cheers,
--
Joerg Jooss
news-reply@joergjooss.de