Bug in the BizTalk WCF-custom adapter

The bug described below, have been confirmed by Microsoft, and I’ve received and tested a private fix. According to Microsoft a simple fix like this will most likely be approved, and if so, it might be included in the BizTalk 2009 Cumulative Update 1 to be release soon (1-2 months).

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:

1. a binding that uses sessions, say the default configuration of the wsHttpBinding, and
2. 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:

http://www.request-response.com/blog/PermaLink,guid,f731e5cc-9490-4f1e-bc7d-efb91f357cd1.aspx

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.

 Best regards

 Michael Brandt Lassen