Web Service Woes (Ah... dry land... dry land at last!)

The band-aid of a fix I did last night appears to have solved the problem. My target application has run all night (as one would expect). This is great! However, now I have a couple of other questions. First, what could possibly be causing one machine to work just fine when using HTTP Keep-Alive and another fail every single time? Now I’m more curious how the network communications actually works when using Web Services, as I was under the assumption that they didn’t work any differently than basically browsing to a web page.

My browser doesn’t puke 5-6 minutes after going to a web site… and I believe that it’s browsing using Keep-Alive. Why does the FCL crash so miserably? This error appears to be related to ANY WebRequest made (which is one of the key components of Web Services). So, not only is this problem with Web Services, but ANY Internet communications over HTTP. Something that seems extremely critical in moving applications forward towards being Internet enabled (Smart Clients ring a bell to anyone!?!?!?); how is it possible this type of problem could even exist? How many people need to report this type of problem before a fix is made? It obviously exists, I’ve came across at least a dozen variations of the same theme… all reporting a similar problem… all reporting an error that can’t be handled… all pointing to the same method deep in the FCL.

I’m usually pretty forgiving with quirks in technology… especially if there’s a work around. However, this one is downright unacceptable in the fact that there doesn’t appear to be any fix (or Q article) on it.

Tonight, at the Fort Worth .NET Users Group, Rob Howard (Program Manager of the Microsoft Web Platform and Tools team for those that don’t already know him) will be there… so you better believe that he will be made aware of this issue ;-) BTW, if anyone reading this is in Fort Worth, get your butts there :-D