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.

Comments

• Anonymous
  January 16, 2008
  Tom, Have you found anything yet on the issue? You might want to run adplus to capture crash dumps. I will try to repro in a week or so once I am code complete with my cuurent project. At this point, I am suspecting that this was caused by the default interception mechanism implemented by PIAB, which uses the .NET remoting proxy. Hugh

• Anonymous
  January 16, 2008
  Hey Hugh - I'm still working on getting a repro outside of my customer project so I can share it. Now that my project is unblocked this has become a spare time activity, but I'm making some progress. Your assessment that it's related to the .NET Remoting proxies sounds accurate, as the exceptions I was getting were thrown from those classes. Still there must be something in the combination of WCF and PIAB which is causing the instability in this scenario. I'll keep you in the loop with what I learn. Tom

• Anonymous
  February 08, 2008
  A recent topic that has come up in discussion is pieces of middle tier patterns and libraries. ...

• Anonymous
  February 18, 2008
  The comment has been removed