Partager via

Avoiding OneWay Deadlocks

  • Article

I have two web services and I'm seeing a deadlock when making calls between them. The operation calls are marked as OneWay. How do I fix this? And, how is it even possible for one-way calls to block?

Marking an operation with the OneWay attribute doesn't offer any magical protection against deadlocks. The OneWay attribute means that in messaging terms, there is no application data that the service is expected to return as a result of the call. However, one-way calls still need to wait for the service to accept transmission of the message. A one-way call is complete when the service acknowledges that the message has successfully arrived (although the definition of successful can vary a bit). We've seen this before in HTTP, where successful acknowledgement takes the form of a 202 Accepted response.

There's a number of reasons then why a service might appear to have deadlocked. The service could simply be really slow and has either not accepted the connection or not finished processing to the point where it can send the acknowledgement. Now that you know that the one-way call can block, it takes more sleuthing before you can declare that a deadlock is taking place. The operation call could be held in limbo for a while because of the ConcurrencyMode setting. Setting ConcurrencyMode to Single prevents the service from taking a second call in while an existing call is underway. The operation call could also be waiting for the SynchronizationContext to become free. Basically, the problem with the one-way call could be almost any of the problems that you'd associate with a standard bidirectional call. Applying OneWay attributes to your calls does not get you out of having to debug your service deadlocks.

Next time: How HostNameComparisonMode Works

Comments

  • Anonymous
    October 18, 2006
    So what is the proper way to make the calls "true" fire and forget?  It seems this is more of a fire, wait to see if you hit your target, then forget.  

  • Anonymous
    October 18, 2006
    After switching from message security to transport security, I'm seeing a bunch of weird protocols being

  • Anonymous
    October 18, 2006
    Mike, that's exactly the right way to think about OneWay tagged operation calls. Having true fire-and-forget means that your channels must be able to return immediately after sending a message.  Typically this requires you to have no delivery guarantees (messages may be lost, duplicated, misordered, whatever along the way).  Datagram transports, such as UDP, are an example of channels that can do this.  Asynchronous transports, such as mail or queues, can be pretty close to fire-and-forget.  They still have to wait for the store to accept the message but they don't have to wait for delivery or processing.

  • Anonymous
    October 19, 2006
    Now that I got my Feed Demon back, I actually have some stuff in the queue that is not so "new" but perhaps

  • Anonymous
    October 23, 2006
    We used the timeout setting to help mitigate a lock or does this only apply to the soapclient call? The default setting is 2 minutes.

  • Anonymous
    October 23, 2006
    The comment has been removed

  • Anonymous
    September 24, 2007
    Now that I got my Feed Demon back, I actually have some stuff in the queue that is not so "new"

  • Anonymous
    December 03, 2008
    Now that I got my Feed Demon back, I actually have some stuff in the queue that is not so "new" but perhaps still "notable." Architecture/CAB/Smart Client Oldie but goodie: Eugenio has compiled a list of CAB and Smart Client Software