C#

WARNING: Serious ASP.NET issue with Windows Server 2003 and SP1

Marcus Mac Innes — Thu, 04 Aug 2005 17:20:00 GMT

We have been trying to track down a problem with our blog aggregator software B.AG which is currently powering INDA's blog aggregator at www.developers.ie/blogs.

We recently upgraded the server to Windows Server 2003 SP1 and for some reason, threads were simply disappearing from our custom threadpool and the application logging which uses log4net would simply stop without warning. We have just tracked the problem down to the System.Threading.Timer class which according to this has major issues when running on Windows Server 2003 with SP1. It seems the Timer class stops firing at some random point and never fires again...

I know of a number of major ASP.NET sites around the world that have applications that depend on functionality provided by the Timer class and I'm very surprised that this issue has not seen more publicity. So this is just a warning to ensure that you don't fall victim to this issue!

As far am I am aware there is no hotfix available for this problem yet.

WS-ReliableMessaging for WSE 2.0

Marcus Mac Innes — Tue, 30 Nov 2004 17:31:00 GMT

Andres has released the code for an implementation of WS-ReliableMessaging via his blog here. I've taken a quick look at the code and it looks good.

There was quite a bit of talk a few months back about how WS-ReliableMessaging should be implemented. The discussion mainly revolved around where the RM Sequence should be created and terminated in the implementation so as fit nicely with the different WSE 2.0 channels. This implementation preserves WSE 2.0 by simply sub classing SoapSender and SoapReceiver and providing a SequenceManager.

Regarding message correlation, Andres's implements a MemoryStorageProvider only, but looking at the code, it would be relatively easy to build the DBStorageProvider which implements IMessageStorageProvider.

Some other nice features include integration with a WSCompression library and a ton of useful Utility classes suitable as good examples for those who are starting out...

Christian Weyer of Plumbwork Orange fame has also indicated that the code might be integrated into the Plumbwork Orange mainline. This would be very interesting and would definitely give Hervey Wilson something to think about (and measure against) for the WSE 3.0 feature list...

Well done to Andres on getting this first implementation (that I have heard of) out there!

TestDriven.NET 1.0 Released

Marcus Mac Innes — Tue, 30 Nov 2004 12:42:00 GMT

TestDriven.NET, a handy addin for Visual Studio which allows you to run unit tests from pretty much anywhere from within VS.NET was released as version 1.0 yesterday...

When is a Unit Test not really a Unit Test

Marcus Mac Innes — Fri, 05 Nov 2004 09:46:00 GMT

Udi Dahan has posted an interesting article for anyone thinking about writing unit tests when implementing Test Driven Development (TDD) here. In the article he explains how the use of mock objects allows test writers to de-couple the implementation of the test code from dependent objects and thus enabling you to have a true "Unit Test".

For more information on mock objects and Udi's use of :

Mock mock = new DynamicMock(typeof(Something)); // create a mock

check out NMock, a mock object framework for .NET.

.NET 2.0 Beta 2 May Be Around The Corner...

Marcus Mac Innes — Sat, 23 Oct 2004 23:43:00 GMT

Scott Guthrie has returned to blogging with this insightful blog about some of the internal project management and testing techniques currently being adopted by the ASP.NET team for the next release of Microsoft ASP.NET 2.0, Beta 2.

Interestingly, Scott mentions that the Beta 2 milestone is now only 3 weeks away... Positive news after this week's announcement of yet another delay to the final release of VS.NET 2.0 and SQL Server 2005.

Maybe it's the SQL Server team delaying things this time in an attempt to put back the diagram!

How to Configure WSE 2.0 Services Behind a NAT Router.

Marcus Mac Innes — Sun, 26 Sep 2004 16:32:00 GMT

When I recently put a bunch of Microsoft Web Service Enhancements (WSE 2.0) services to the test across an Internet based connection I was in for a surprise…

I hadn’t counted on the problem of trying to configure WSE to work behind our “Gateway to the Internet”, the Network Address Translation (NAT) router!

Our office LAN sits behind a router/firewall which ‘protects’ it from the 2Mbit broadband Internet pipe. All but the necessary TCP/IP ports are blocked and all workstation machines are running Windows XP Service Pack 2 with the firewall enabled.

The preliminaries to getting it all running include the usual:

1) Opening up the relevant TCP/IP port on the firewall. (The default port for the soap.tcp transport is 8081)

2) NAT mapping of the router port 8081 to the test server or workstation’s port 8081.

3) If using Windows XP SP2 as a test machine, then add the service host application to the list program exceptions for incoming network connections in Windows Firewall.

And this is where it gets a little tricky…

A problem arises from the fact that the external IP address belongs to the router and not the machine which is hosting the service. This machine hosting the service has its own internal IP address which is not visible from the outside.

But WSE doesn’t allow binding a SoapService to an IP address that is not local to the machine. i.e. you cannot bind to the router’s IP address, you can only bind to a address such as localhost.

If you try, you get the following error: WSE813: The following transport address could not be mapped to a local network interface: soap.tcp://<RouterIPAddress>.

Furthermore if you bind your SoapService to localhost then all incoming network connections that originate from the local network are received by WSE and are served correctly. Incoming connections that originate from outside the firewall however are addressed to the router. Since the router (using NAT) is configured to map these incoming connections to the internal machine which is hosting the service, the message is indeed routed to the correct host application…

But upon receiving these external messages WSE rejects the request and reports “Destination Unreachable” back to the client. The reason for this is simple, WSE uses WS-Addressing and the wsa:To address is not referencing this machine, its referencing an endpoint on the router.

After some investigation, trial and error and finally common sense, the answer was quite simple, employ the use of WS-Addressing’s wsa:Via as follows.

Register the SoapService using a logical name such as “MyService” and a Via: specifying the IP address of the machine hosting the service:

MyService service = new MyService();
Uri logical = new Uri("urn:MyService");
Uri via = new Uri("soap.tcp://<ServiceHostIPAddress>");
EndpointReference epr = new EndpointReference(logical, via);
SoapReceivers.Add(epr, service);

On the client you do something similar except specify the router’s IP address:

public class MyClient : SoapClient {
    public MyClient() : base(
        new EndpointReference(
        new Uri("urn:MyService"),
        new Uri("soap.tcp://<RouterIPAddress>")) {}
}

Easy as that!

Synchronized .NET Collection Classes are NOT Thread Safe.

Marcus Mac Innes — Tue, 21 Sep 2004 12:01:00 GMT

Call me a purist, but when someone asks me whether something is thread safe, I like to re-phrase the question in my head to something like "Is this air traffic control system thread safe" before answering...Yes or No?

So you can imagine my surprise then after finally tracking down a threading issue only to discover that the bug was in fact caused by the .NET synchronized Hashtable and it turns out that the synchronized Hashtable is in fact not thread safe, but thread safe "ish" and to me that's NOT thread safe at all.

The documentation for Hashtable and other collection objects which implement System.Collections.ICollection indicates that the static method Synchronized "Returns a synchronized (thread-safe) wrapper for the Hashtable.". Creating one coundn't be simpler, a small change in the Hashtable's initialisation provides you with thread safety...

Hashtable threadSafeHashtable = Hashtable.Synchronized(new Hashtable());

The Hashtable class contains a private class called SyncHashtable which simply subclasses Hashtable and overrides its properties and methods. In reality, these wrappers synchronize data access by simply wrapping access in a lock statement. Here is the Hashtable's synchronized Add method:

public override void Add(object key, object value)
{
      lock (this._table.SyncRoot)
      {
            this._table.Add(key, value);
      }
}

Perfect right?

Well not exactly... You see the Add method above is thread safe. Only one thread can add to the Hashtable at a time. But if we look a little closer, we find that not all properties and methods provide lock safety. Here is the implementation of the indexer which you will notice is missing a lock on the "get":

public override object this[object key]
{
      get
      {
            return this._table[key];
      }
      set
      {
            lock (this._table.SyncRoot)
            {
                  this._table[key] = value;
            }
      }
}

This is a typical example of naive thread safety. The assumption goes that mutliple threads can simultaneously read from an object safely, but only one thread at a time can write to the object safely. And this is the implementation we see in System.Collection.Hashtable (above).

This design works perfectly well and provides optimum performance since we are not holding up threads who only wish to read an objects data, they simply work away oblivious to each other, only when a thread wishes to write does it need to synchronize its access to the data. There is however one HUGE assumption in this design, the writes must be "atomic".

In some cases writes to memory locations are actually atomic. For instance setting a value of a bool or int on 32bit single processor machine in .NET 1.1 just happens to be atomic. We run into problems on multi processor machines however due to processor level memory caching and often need to qualify writes with System.Threading.Thread.MemoryBarrier() (discussed here) which flushes the processor's memory cache. But now we have 2 separate statements which together are definitely not atomic.

So why is this important when looking at the synchronization design of the System.Collections.Hashtable.SyncHashtable class?

Well if a thread always has the green light to perform a read, then it makes the assumption that the data to be read exists in a fully written state. If it were allowed to read "while" another thread was in the middle of write (albeit one thread writing at a time), then the data could be half written when the read is performed and hence we have a subtle and often difficult to locate threading bug.

Other methods on SyncHashtable that fall foul of the design flaw include: Contains, ContainsKey, ContainsValue, CopyTo, GetEnumerator, GetHash and KeyEquals.

Don't get caught out!

[Update:] As of .NET v2.0.40607 SyncHashtable.CopyTo has been upgraded to include a lock.

HOTFIX 831419 makes the list for .NET 1.1 SP1

Marcus Mac Innes — Wed, 01 Sep 2004 11:22:00 GMT

Eric Gunnerson blogs about the recent release of .NET 1.1 SP1 here. For those of you that were hoping for the inclusion of HOTFIX 831419 which is not listed in the list of official bug fixes, don't dispair... It's in there!

[edit] Omar gives a short code example here for using the fix.

TechEd 2004 Europe - Day 3

Marcus Mac Innes — Mon, 05 Jul 2004 12:07:00 GMT

Following on from my previous blog, the highlights of day 3 had to be my friend Bill O'Brien's talk on Patterns in the Enterprise (ARC309) and Clemens Vasters' Best Practices for Dealing with State at Multiple Layers Within Your .NET Applications (CTS404).

Bill took the audience on a journey of software development, carefully explaining key concepts from the ground up. He discussed the real life difficulties of "code re-use", the Holy Gail of software development and suggested a much better take home, "knowledge re-use". Using Patterns he explained, member's of the team have a whole new vocabulary with which they are able to communicate vast amounts of information in a single sentence.

Bill went on to give some real life examples of well known patterns such as Model View Controller (MVC) and Factory, before introducing some less well known Enterprise Patterns such as Integration and Enterprise Solution. Using Microsoft's pattern diagram, Bill explained where patterns fit in relation to one another and how they can be grouped into "clusters" which provide assistance in making more informed choices. Overall a very difficult topic, delivered with excellence!

Clemens did his usual wizardry on the audience and gave everyone good reasons to bow down to anything he might say regarding COM+. His talk was on State Management and started out by explaining why there was no such thing as "Stateless". While everyone is told over and over again that keeping state is "bad", he explained why keeping state is often "good". In a clever observation, he explained some of the internals of the Garbage Collector and why not using session state is wasteful since the data is more than likely still around from the previous call, waiting to be garbage collected.

He backed this up with an example of using .NET Weak References to tentatively hold on to objects in Session State. This has got to be the cleverest piece of code I have seen so far at the conference and as usual, Clemen's code examples are not lightweight, they are always production quality.

These and other code examples from Clemens, including very clever and best practice use of COM+ are going to be made available in the forthcoming release of Proseware.

TechEd 2004 Europe - Day 2

Marcus Mac Innes — Mon, 05 Jul 2004 11:22:00 GMT

Following on from yesterday, Frans Bouma MVP creator of LLBLGen Pro gave his long anticipated BOF (BOF003) session today on Object Relational (O/R) Mapping using .NET.

Most of the people attending were probably still in shock over the delay / cancellation of Objectspaces in .NET 2.0 and were looking to see what alternatives were available. In good honest tradition, Thomas Tomiczek MVP creator of EntityBroker gave everyone a taste of his personal debating style which was not dissimilar from his infamous online approach. Thomas however is one clever guy and made no mistakes in what he was saying. Meeting him in person and having in depth discussions with him afterwards made me realise that he is after all, one hell of a nice guy despite what your read in the newsgroups!

There was a consensus of confusion surrounding where exactly O/R mappers are required. Some advocated the use of hybrid systems (which I do not recommend) which combine O/R mapping layers with faster direct database access methods for read only operations. While this *might* achieve better performance, you have to way up the cost of loosing maintainability and database independence.

Well done Frans on a lively and rounded debate.