0

I have a WCF duplex service with a 2 way method called GetList, plus a one way callback method ItemUpdated.

I've detected a deadlock in the following situation:

  1. The service calls the ItemUpdated callback, which is handled in the client by the method OnItemUpdated.
  2. Before the previous method returns, some user interaction causes the client to call GetList on the service.

I could set the ConcurrencyMode of my service to Reentrant, but that's not what I need. What I need is to make sure that my client is not processing any callback from the service before calling GetList.

So I can synclock an object to make sure that this doesn't happen. Is that my better alternative?

UPDATE:

Just to clarify what my current design is, my service is actually a windows service that does some processing on a list of objects on a schedule and when each item is updated it raises the event ItemUpdated. This service has a WCF service facade that allows one or many consoles (clients) to subscribe to its events and see what is going on in the service.

Mike
  • 753
  • 1
  • 7
  • 16
  • What are your ConcurrencyMode and InstanceMode now? – H H Aug 30 '12 at 19:23
  • In all likelihood, "locking" is only going to make things worse :) Words like "two way" and "duplex" are potentially scary - your service should be designed to be *stateless*, if at all possible. Messages in both directions - sure. One thing on one host waiting on something from the other host: please revisit the protocol you've designed. *Definitely* look at ErnieL's response, and read the link he posted. It's good advice, IMHO... – paulsm4 Aug 30 '12 at 21:35
  • @paulsm4: I've updated my question to clarify my current design. As I mention there, my service is a windows service so it cannot really be stateless. Also, I don't see how two-way (as opposed to one-way) methods are scary. I'll concede that duplex services are harder to design and maintain, and how using them for a provider-subscriber pattern might be an arguable decision. – Mike Aug 31 '12 at 14:29

2 Answers2

2

InstanceContextMode = Single together with ConcurrencyMode = Single causes WCF to serialize all the calls to your single instance. In other words WCF has created a lock to enforce serialization. This is the cause of the deadlock. Adding yet another lock might work. But you are proposing a client lock... the client shouldn't have to change its threading behavior to keep the service from deadlocking. The service needs to be more robust than that.

This is a service issue. You should create a more robust service.

I would suggest changing the service to remove the serialization and prevent the possibility of deadlock entirely. My suggestion (in order that I would try):

  1. Change the service's InstanceContextMode to PerCall. The "preferred" design is to have the service be stateless. Create a different service instance for each call removes the forced serialization. Store all your state information in a common store (for example a database or cache).

  2. Have the service make the ItemUpdated callback on a different thread. This allows the service thread to complete before the callback is done. The problem with this solution is that if the ItemUpdated callback throws an exception the service is no longer waiting to catch and handle it. This means good error handling is harder.

See Discover Mighty Instance Management Techniques For Developing WCF Apps for more information.

ErnieL
  • 5,773
  • 1
  • 23
  • 27
0

The problem was not really on the service but on the callback handler in my client. This is basically what was happening:

  1. My service raises an event that calls ItemUpdated on the client.
  2. While the callback is still processing ItemUpdated, the user forces GetList to be executed.
  3. The service receives the request and sends back the result of GetList, but my client cannot process the response from the service because it is already processing another callback.

So I ended up changing the ConcurrencyMode in the callback using the CallbackBehavior attribute. The service remains with ConcurrencyMode = Single.

Mike
  • 753
  • 1
  • 7
  • 16