The last few days I’ve been hunting down a problem which is quite common under users of WCF. It seems WCF will only honor a specified amount of concurrent connections ( at default this will be 10 concurrent connections ) before ‘freezing’.

The most common causes of this ‘freeze’ are :

  • forgetting to Close() the client proxy (and connection) when you’re done processing
  • forgetting to call Abort() on the client proxy  whenever an exception has been thrown
  • using the ‘using (…) { }’ construction on the wcf client proxy.

When you forget one of these the connection will not be closed. ( or it will be closed later on by the framework itself, but that’s most likely not the way you want it. )

Sounds pretty easy right? Just enclose the proxy calls in a try – catch and make sure the connection gets closed properly.

It’s not that easy when you are using BizTalk Server as an endpoint. There are a few caveats when you’re having a complex ( multi application ) BizTalk solution which is using WCF adapters for its logical ports.

  1. Make sure when you use request/response ports to always return a response message, even when things fail in your orchestration(s). When you terminate the orchestration without returning a response, the connection will not be closed.
  2. When you have a multi application solution it gets even more important to do it right.Lets say you have an already existing (almost legacy) application which has a logical request/response port ( which is bound to a WCF receive location ) and this port has a fault operation, which works fine with the receive location itself. You have created an application which internally uses you’re existing application using the same logical port, and it has it’s own entryport, which is also a send/receive port using WCF as its receive location.

    You now need to be very sure that the new application uses  the send and receive actions and handles possible fault messages from the legacy application. Say the new application will send the old application a message and will wait indefinitely for an answer on the response operation, but the legacy application fails and sends a message on the fault operation, which isn’t picked up by the new application. This new application will never close the opened connection on the WCF receive-location.

If this happens about 10 times, it’s the end of the story for the new application receive location and it won’t respond anymore ( it hangs so-to-speak… ) The only thing you can do then is to forcibly stop and start the application pool ( when the receive location runs in the isolated host ) or the biztalk server process.