ThreadPool default thread count not useful for testing

Today I got reminded again that it is sometimes required to adjust thread pool settings. This time to test some possible connection issues and I required to open a number of connections simultaneously and also use them in parallel.

The test system is a virtual machine which only has one core so the defaults that .net uses are based on that. I first thought that the problems were caused by nunit but pretty soon found out that the case had to do with the thread pool. When I queried the current values via ThreadPool.GetMinThreads it told me that the thread pool used just one thread as minimal. After forcing that with ThreadPool.SetMinThreads to a thread count in where I could test my scenario I still had issues.

I am now using a custom Parellel.For which I adjusted so that I can set a different ChunkSize (set to 1) and ThreadCount for testing purposes.

WCF and DateTime.Kind pitfall

At my job (Company Webcast) we have several API’s for our customers to use. One of those API’s allow webcasts to be created and modified and that interface has data containing dates. Our platform works with UTC date time’s as we are an international operating company so it is logical for use to store those as UTC.

We use WCF and yesterday we had a very weird issue where calls failed. After investigating the issue we found out that the cause was that how the date time got supplied to our service in the message

The following values are valid in an XML message:

<ns1:ScheduledStart>2010-05-26T17:00:00+02:00</ns1:ScheduledStart>

<ns1:ScheduledStart>2010-05-26T15:00:00Z</ns1:ScheduledStart>

A WCF service accepts both values but it treats them different which I did not expect! The first value became 2010-05-26 17:00 where DateTime.Kind is set to Local and the second becomes 2010-05-26 15:00 with DateTime.Kind set to UTC. This amazed me a bit as I assumed that both would always result in either a UTC or Local DateTime.

The reason it fails is that another argument states the time-zone from where the live webcast will be held. This is used in combination with the DateTime to convert the DateTime value to a local time to inform the viewer about the conditions of the event. This code assumed that the incoming DateTime value would always be of kind UTC.

So now our front-end api’s convert incoming DateTime values to a DateTime value with kind UTC.

This could also be a problem when you persist this DateTime to for example a database and your storage logic does not convert the DateTime from/to UTC or Local depending on your needs. We use NHibernate for storage and it does not by default has a way to set UTC/Local to a <property> definition. This can really become a problem when time is part of your business logic as it is in ours as we use it to schedule tasks and it is very important to know it a time is UTC or not especially when something happens on the other side of the world.

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