A Follow-up on PIAB+WCF Integration

Last month I posted an entry describing how to invoke the Policy Injection Application Block at WCF service boundaries by using custom WCF behaviours. Since then I've discovered a couple of new things that I thought you might be interested in.

First, my (OK, actually my wife's :-) February 2008 issue of MSDN Magazine arrived in the mail last week. It contains an article by Hugh Ang and David San Filippo on the exact same topic (source code is here, article is here). Hugh and David's implementation is a little slicker than mine - it hooks into the IInstanceProvider extensibility point rather than the IOperationInvoker that I used - the advantage of their approach is the PIAB wrapping is only executed at the time the implementation object is created, rather than every time the operation is invoked. Still, I win the award for getting a solution published first :-)

The other piece of news is that I tried integrating both solutions into my project, and things did not go at all well. In a simple test scenario both worked fine, however in my application, which involves multiple WCF service communications, the application suddenly became extremely unstable. Tests would pass and fail intermittently, the PIAB infrastructure would complain about incompatible types, and occasionally the entire CLR went down with a Fatal Execution Engine Exception. In short, bad stuff. The results were also identical using my original solution and with the MSDN Magazine version.

I never found out exactly what was going on, but I did get a couple of clues. When we had just a single service boundary (Service A talking to Service B), everything was fine. The instability started when we had Service A talking to Service B talking to Service C. In our development environment we have everything hosted in separate IIS applications on the same box. When I reconfigured the applications to run in their own app pools, things became stable again. So it looks as if something about the PIAB/WCF approach is causing some kind of leakage across different services running in the same process. If anyone else can repro or has any theories on the underlying cause, please let me know.

It is possible that the problem we experienced is caused by some other aspect of our solution, so I wouldn't discount this approach altogether without some more testing - however I would recommend exercising a lot of caution. In the end I decided to take my call handler logic (in this case, an improved implementation of exception shielding) and call it directly from a new WCF behaviour without the use of PIAB. This time everything ran smoothly - but it's just not as pretty.