Category name:services

Long delay at service startup caused by WebRequest.DefaultWebProxy

Today I was resolving an issue where some of our services had a very long startup time which only occurs during booting and not at a service start/restart from the service snap-in. In other words, when I restart the service when the system is finished booting than we experience no delay.

After debugging through logging I found out that the System.Net.WebRequest.DefaultWebProxy was causing our delay of almost two minutes! The problem is that this is a property! Property access should be fast so this should have been System.Net.WebRequest.GetDefaultWebProxy().

After searching (aka. googling) it seems to be something related to WPAD which does automatic proxy server detection. I tried overriding the proxy configuration by adding the following to the app.config but without any success.

   <defaultProxy useDefaultCredentials=”True”>
      <proxy useSystemDefault=”False” autoDetect=”False”/>

Without retrieving the default configured .net proxy server the service starts very fast.

I guess I’m dependant on one or more services but didn’t find any except “Tcpip” and “Dnscache” and making our service dependant on these services didn’t help at all.

The conclusion is not to use “WebRequest.DefaultWebProxy” in a service as it will delay your service startup time. WebRequest.DefaultWebProxy is probably meant to be used in desktop applications.

I now created our own version of an IWebProxy locator that can be configured to use the WebRequest.DefaultWebProxy or any other implementation. For example, we have a couple or services where the settings should be saved between uninstalls, upgrades, etc. In our custom implementation we use a we use isolated storage for platform wide settings.

Don’t hate soap use it for its standards

I tried commenting on Udi Dahan‘s blog on his article “I hate wsdl” but it if failed so I respond from my blog.

Udi Dahan is ranting on soap after Ted Neward article. Ted says:


WSDL creates tightly-coupled endpoints precisely where loose coupling is necessary, WSDL encourages schema definitions that are inflexible and unevolvable, and WSDL intrinsically assumes a synchronous client-server invocation model that doesn’t really meet the scalability or feature needs of the modern enterprise. And that’s just for starters.

Udi’s opinion is that soap prevents a few one-way messaging patterns where you have one request and multiple responsed.

I disagree with his opinion. First of all, soap *does* support one-way messages. Soap works good in fire and forget designs and the behavior is standardized. For an example in his one request multiple responses. This is the exact behaviour that you have with upnp routers with over udp.

The good thing of soap is that it is transport neutral and that it has *standard* ways in the messages level to add reliable messaging, routing, authentication and encryption. Ignoring these powerful attributes is just plain dumb! Soap is meant to lower communication between systems based on contracts including architectural decisions and all in transport neutral context! Loose coupling to the max without sacrifice’s in data *and* transport contract because the ‘transport’ doesn’t support certain requirements.

I’m not a soap advocate and I don’t promote it at all. Lots of situations where you don’t need all this complexity but these are often the scenarios where you don’t need to think about a ‘service bus’ solution at all. And if you do need it than I am a fan of a full soap aware servicebus. Too bad there are none on the market that comply to soap standards but it isn’t that difficult to write a soap broker for a few situations in a couple of days.

The only reason I hate soap is that there are several communication styles in the form of rpc/document format, the interoperability issues between frameworks and often the soap framework flexibility to easily add custom/pluggable behavior to influence all soap messages.

Tim’s comments of soap indicate two things. The first is his inexperience with soap and the second is his assumptions that interfaces should be flexible (quote: “WSDL encourages schema definitions that are inflexible and unevolvable”). I always learned “interfaces once defined cast in stone”. If you want to change the interface then you need to define a new interface based on the original interface and change it. I surely hope Udi doesnt share Tim’s opinion on this as that would result in an immediate deletion of his blog in my feed reader!

  • Recent Posts
  • Recent Comments
  • Archives
  • Categories
  • Meta