Blog from Saravanan Arumugam

Let us talk about Technologies

Category Archives: wsDualHttpBinding

This operation would deadlock because the reply cannot be received until the current Message completes processing.

I got the following exception when I attempted to create a Duplex channeled service.


This operation would deadlock because the reply cannot be received until the current Message completes processing. If you want to allow out-of-order message processing, specify ConcurrencyMode of Reentrant or Multiple on ServiceBehaviorAttribute.

I got this exception because I didn’t change the concurrency mode of the service. By default the concurrency mode is single. But the duplex operation would require the service instance to be called concurrently.


As suggested in the exception message itself, when I set the Concurrency mode to Multiple it got resolved.

Reentrant is also applicable for duplex services however the choice of Multiple or Reentrant concurrency is up to the design.

    [ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]

    public class GreetingService : IGreetingService


HTTP could not register URL … because TCP port 80 is being used by another application

When I used a Duplex channeled binding (wsDualHttpBinding), during the run time I received the following exception.


HTTP could not register URL http://+:80/Temporary_Listen_Addresses/634f73f6-c612-4441-acf8-79ddd5c62f98/ because TCP port 80 is being used by another application.

This is because the port 80 is being used by the IIS (the default web site uses Port 80) and the callback from the service attempts to register the same port for communication.


The solution to this is to instruct the WCF to use a different port. I had to add the following binding configuration.



        <binding name="wsDualHttpBinding_IGreetingService" 





I also had to specify the bindingConfiguration in endpoint to point to this.

<endpoint address="ws" binding="wsDualHttpBinding" 


But unfortunately specifying the clientBaseAddress in service configuration doesn’t take part in the WSDL. As a result clientBaseAddress won’t show up in the client side config. There is no negotiation happening during the runtime either.

So instead of providing the clientBaseAddress in the service side, create the proxy and config as usual and then provide the clientBaseAddress by modifying the client side configuration.

As a result, the client side configuration should typically be looking like this.

              <binding name="WSDualHttpBinding_IGreetingService"
                <security mode="Message">
                  <message clientCredentialType="Windows" 
                      algorithmSuite="Default" />
            <endpoint address="http://localhost:54927/GreetingService.svc/ws"
                    <userPrincipalName value="xxx\xxxx" />

Note: By default the Visual Studio would not be able to register even http://localhost:8088/clientCallbackUrl if it is used for the first time due to security constraints.

Refer to HTTP could not register URL for further detail.

An alternate solution to using netsh command is to run the Visual Studio itself in Administrator mode.