Now for the details on the bug:
Lately I’ve been working with the WFC-custom adapter in several exception handling scenarios on BizTalk 2009.
Recently I’ve discovered a bug in the BizTalk WFC-custom adapters handling of WCF-faults in cases where we have:
- a binding that uses sessions, say the default configuration of the wsHttpBinding, and
- a WCF-custom send port that doesn’t propagate wcf faults
In this case, in the default configuration, the WCF service hangs after 10 typed WCF-faults.
If we use WCF service throttling on the server, setting maxConcurrentCalls, maxConcurrentInstances and maxConcurrentSessions the service hangs after min(maxConcurrentInstances, maxConcurrentSessions), that is after two call in the throttling example above.
Apparently, in the case of a typed WCF fault, the BizTalk WCF-custom adapter doesn’t end the connection properly. On the other hand, if the server returns the non typed WCF fault the service doesn’t hang (returning non typed WCF faults isn’t best practice though).
After reading Matevz Gacnik's Weblog:
and a bit of experimenting with a simple WCF-client, we realize that different WCF exceptions need different actions when ending the connection: Handling a typed WCF fault should include a call to the client proxy method Close, as is the case for successful calls. On the other hand: handling, say TimeoutException, CommunicationException and non typed WCF faults should include calls to the client proxy method Abort.
This is due differences in the communication state of the client proxy in each situation. If the client state is faulted then abort should be called. If the client state is opened then Close should be called.
The bug in the adapter is due to the fact that the BizTalk WCF-custom adapter doesn’t call Close on the client proxy in the case of a typed WCF fault leading the service hang in the situation described above.
Michael Brandt Lassen