[To Be Designed]

WSE Tracing Filters: Just Say No

Let me start by saying that Microsoft's WSE (Web Service Extensions) is a great framework. We've using its messaging API to build a foundation for a service architecture that should transfer relatively easily to Indigo, and its functionality is, on the whole, impressive.

That said. I have to wonder what the team was thinking in some areas. For example, the tracing filters are pretty much unusable except for very brief "let me take a peek" tracing sessions. We discovered this as our QA group was doing functional testing of our SOAP-based windows services. We delivered builds to QA with tracing turned on, and also included Simon Guest's WSE Trace Tool in the build so they could troubleshoot any message delivery problems they might run into. What a bad idea that was!

It turns out that in order to dump fully-formed XML documents to disk as the input and output traces, the filters just append each incoming or outgoing message to a private member XML document. Each filter also maintains a private filestream member. Each time a message enters or leaves the WSE pipeline, the stream pointer is set to 0 and the entire XML document is saved to disk. If you don't believe me, just use Reflector and take a look for yourself.

It doesn't take higher math to figure out that this very quickly results in a huge memory footprint and a thrashing GC. The size of the document very quickly makes its strings candidates for the large object heap, and every disposed string is larger than the previous one. With no compaction in the LOH, this creates a very interesting situation that is the GC equivalent of trying to put square pegs into round holes. After a very short time with tracing turned on, one of our test machines was maintaining two XML documents of over 100 MB each, and SciTech's .NET Memory Profiler (awesome tool) showed a GC that was flopping around like a fish on the bank. I'd sure like to hear some rationale for such a silly design decision.

posted by BailWatch Author @ 11:37 AM