The Inquisitive Coder - Davy Brion's Blog » .NET bugs

More On System.Tuple And Serialization/Deserialization

Davy Brion — Wed, 23 Jun 2010 19:19:07 +0000

As i mentioned in my last post, i ran into a serialization problem with a Tuple reference when returning it from a WCF call. It failed with the typical exception you get when a type can not be deserialized. Unfortunately, the message of the exception that i got is the same as it is when a type can not be serialized, though both situations are actually quite different. One of my readers left a comment saying that he didn’t have problems serializing/deserializing a Tuple (by the way: am i the only one who has major problems with typing the word ‘tuple’? whenever i wanna use it, i always end up with ‘type’ before i realize my mistake) through WCF.

So why did it work for him, yet failed in my situation? The answer turns out to be quite simple. If you look at the Tuple type of .NET 4 in Reflector, you’ll see this:

So it actually is serializable. The thing is, my client is not a .NET project, it’s Silverlight. And the Tuple type in Silverlight looks like this:

Silverlight still doesn’t support the Serializable attribute and the Tuple types don’t have a parameterless constructor, so that’s why it can’t deserialize a Tuple instance when it’s returned from a WCF call. I can’t believe i didn’t think of this earlier since i’ve been bitten by this problem a few more times (not with the Tuple type, but with other Serializable classes) in the past, but then again, i can’t believe something like this still doesn’t work when using .NET 4, Silverlight 4 and WCF 4 together.

My First Request For The Next .NET Version

Davy Brion — Wed, 23 Jun 2010 11:38:37 +0000

Please, pretty please, make the Tuple class serializable… i just got this exception:

Type 'System.Tuple`2[System.Guid,System.Nullable`1[System.Guid]]' cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute. Alternatively, you can ensure that the type is public and has a parameterless constructor - all public members of the type will then be serialized, and no attributes will be required.

That’s all… now if you’ll excuse me, i gotta go include a useless DTO in my project.

MSDTC Woes With NServiceBus And NHibernate

Davy Brion — Fri, 19 Mar 2010 10:52:16 +0000

I’ve spent about 3 days trying to get something working that should’ve just worked. I basically wanted some .NET code to use a distributed transaction to update some data in a database, and then publish a message on the service bus. I want to do this in a distributed transaction because if something goes wrong, i want to roll back both transactions (the database change and the published message). Normally, this should just work if you have MS DTC configured correctly. On my machine, i enabled Network DTC Access, and allowed outbound transaction communication. On the database server, Network DTC Access was already enabled and both outbound and inbound communication was allowed.

Now the thing is, i’d either expect DTC to fail outright or to just work. But it shouldn’t fail in one situation, and work in another. On my machine, it failed in the following situation (which i’ll further refer to as Situation A):

open a transaction scope
open an nhibernate session
hit the db
publish a message through nservicebus
close the nhibernate session
complete and close the transaction scope

Step 4 and 5 could be switched around but it didn’t make a difference. In Situation A, i always got a TransactionManagerCommunicationException with the following message:

Network access for Distributed Transaction Manager (MSDTC) has been disabled. Please enable DTC for network access in the security configuration for MSDTC using the Component Services Administrative tool.

Everyone who’s worked with MSDTC before probably knows that exception since it usually takes some fiddling with the settings to make things work. The thing is, i was pretty sure that my settings, as well as the ones on the database server were correct. Unfortunately, DTCPing didn’t confirm that since that too failed.

However, i also tried the following sequence of events (Situation B):

open a transaction scope
open an nhibernate session
publish a message
hit the db
close the nhibernate session
complete and close the transaction scope

And guess what. That actually worked. With full DTC transaction semantics. The DTC statistics on the server confirmed that it was indeed using a DTC transaction, and if i made the code fail with an exception both the database action and the published message were correctly rolled back.

So the question is: why on earth does it only work when i publish a message before i hit the db?

During my investigation i noticed that in Situation A, the internal transaction that the transaction scope was using was a SqlDelegatedTransaction. Which, if i’m not mistaken is an LTM transaction. When trying to send a message to a message queue, the transaction manager tries to promote the current transaction to an OletxCommittableTransaction since the OleTx transaction protocol is required when using MSMQ (it doesn’t support LTM transactions). For some reason, promoting the SqlDelegatedTransaction to a full DTC (OleTx) transaction fails on my machine.

In Situation B, the internal transaction is promoted to an OletxCommittableTransaction as soon as you try to send the message to a message queue. Once it’s time to hit the DB, NHibernate nicely works together with the OletxCommittableTransaction and everything just works.

Now, i have no idea on earth why promotion of a SqlDelegatedTransaction fails, but after a long number of attempts and experiments to get it working correctly, i sorta gave up and figured i’d have to resort to a hack. What i basically needed was for the transaction scope’s internal transaction to automatically be promoted to an OletxCommittableTransaction before i’d hit the database and without having to publish a dummy message at the beginning of the transaction.

I found one way of doing this which, while being a huge hack, is still relatively clean i think. I wrote the following class:

    public class DummyEnlistmentNotification : IEnlistmentNotification
    {
        public static readonly Guid Id = new Guid("E2D35055-4187-4ff5-82A1-F1F161A008D0");
 
        public void Prepare(PreparingEnlistment preparingEnlistment)
        {
            preparingEnlistment.Prepared();
        }
 
        public void Commit(Enlistment enlistment)
        {
            enlistment.Done();
        }
 
        public void Rollback(Enlistment enlistment)
        {
            enlistment.Done();
        }
 
        public void InDoubt(Enlistment enlistment)
        {
            enlistment.Done();
        }
    }

Then, right after opening the transaction scope and before doing anything else, i do this:

    Transaction.Current.EnlistDurable(DummyEnlistmentNotification.Id, new DummyEnlistmentNotification(), EnlistmentOptions.None);

This basically tells the System.Transactions infrastructure that we’re adding our own Resource Manager to the current transaction. And because it’s a durable Resource Manager, it now automatically promotes the internal transaction to an OletxCommittableTransaction and everything just works. While our Resource Manager participates in the 2-phase-commit process, it doesn’t actually do anything. It’s sole purpose is to force the creation of an OletxCommittableTransaction.

Like i said, it’s a hack but it’s still relatively clean. I still have no idea why i needed to resort to this hack though… If anyone can shed some light on this, i’d highly appreciate it

Also, if you ever want to learn more about transactions in .NET or distributed transactions in particular, you really need to check out this article. Without it, i probably wouldn’t have figured out what to do

The Joys Of Debugging ASP.NET Memory Leaks

Davy Brion — Mon, 06 Apr 2009 20:37:14 +0000

One of my coworkers describes a very interesting memory leak he just fixed. Be sure to read his post to get the entire story.

We basically had a custom UserControl which contained (among other things) a Repeater which would render another custom UserControl. Nothing really weird there, right? The problem was that the custom UserControl that was created by the Repeater explicitly needed to be disposed. No problem, System.Web.UI.Control implements IDisposable so we could just override the Dispose method, perform our cleanup there and then proceed with the base Dispose implementation.

Now, i'm far from an ASP.NET expert but i was under the impression that all Page and UserControl instances would always have their Dispose method called if they were created by other ASP.NET controls (containing pages or controls). After all, what's the point in implementing IDisposable in the base Control class if you're not even going to guarantee proper usage of the pattern, right?

Well, as Kristof describes in his post, there is at least one situation where a UserControl is not disposed of, even though it was created by a Repeater. In our case, the leak was subtle. It took a stress test of 10 hours with a load that would be comparable to real world usage of one month to expose the leak. A lot of people would say "oh, let's just recycle the application pool periodically and everything is A-OK". But the very idea of having to recycle an application pool periodically to keep a system up and running is just a cop out to me. Good code should not require periodic restarts. Period.

I wonder how many ASP.NET WebForms applications might actually have the same (or at least similar) problem(s) like the one Kristof encountered. If everyone keeps recycling their application pools periodically, we unfortunately may never found out.

Exceptional Exception Handling Behavior

Davy Brion — Wed, 08 Oct 2008 16:48:59 +0000

We ran into a weird issue at work today. Take a look at the following code:

    public class MyException : Exception { }
 
    [TestFixture]
    public class TestFixture
    {
        [Test]
        public void Test()
        {
            var exception = GetThrownException<MyException>(() => { throw new MyException(); });
            Assert.IsNotNull(exception);
        }
 
        private T GetThrownException(Action action)
            where T : Exception
        {
            try
            {
                action();
            }
            catch (T exception)
            {
                return exception;
            }
 
            return null;
        }
    }

If you simply run that test, without debugging, it works (both with Testdriven.NET and Resharper). If you run it with a debugger, it fails with the following message:

ExceptionWeirdness.MyException: Exception of type 'ExceptionWeirdness.MyException' was thrown.

Pretty weird huh?

Let's change the code of the GetThrownException method to this:

        private T GetThrownException(Action action)
            where T : Exception
        {
            try
            {
                action();
            }
            catch (T exception)
            {
                return exception;
            }
            catch (Exception e)
            {
                return (T)e;
            }
 
            return null;
        }

Now the test works all the time, even with the debugger attached.

Weird huh? At first i wondered if it was somehow NUnit related... but then i tried running this program:

    public class MyException : Exception { }
 
    class Program
    {
        static void Main(string[] args)
        {
            var exception = GetThrownException<MyException>(() => { throw new MyException(); });
        }
 
        private static T GetThrownException(Action action)
            where T : Exception
        {
            try
            {
                action();
            }
            catch (T exception)
            {
                return exception;
            }
 
            return null;
        }
    }

Run it without the debugger, and it works. Run it with the debugger and it fails.

This is using .NET 3.5 SP1.

I don't understand why it behaves like this... it should work all the time right? I am overdue for my weekly brain-fart so i might be missing something really stupid though.

Either way, the first person to explain this behavior gets awarded with the "Davy Brion's Hero Of The Week" title

Oh, and this was in a clean solution... so there's no duplicate MyException types or anything like that.

XDocument’s WriteTo method gotcha

Davy Brion — Fri, 25 Apr 2008 15:12:47 +0000

Suppose you have an xml document in memory using an XDocument instance. Then you need to write the contents of the xml document to an XmlWriter... no worries, the XDocument class provides the WriteTo method which takes an XmlWriter as a parameter. The contents of the xml document are then nicely written to the XmlWriter.

Unless... you're using an XmlWriter which was created with an XmlWriterSettings instance with OutputMethod set to XmlOutputMethod.Text and your xml document is larger than 6144 bytes! The writer will only write the first 6144 bytes and after that, it just stops. No exception, no nothing. The method returns as if everything was OK. But the underlying stream your XmlWriter wrote to contains faulty data. A very nice way to spend a friday afternoon

In case you're wondering why: The XmlWriter's static Create method creates an instance of XmlUtf8RawTextWriter when OutputMethod is set to XmlOutputMethod.Text. This specific Writer has an internal buffer which is initialized in its constructor to be 6144 bytes long. Apparantly, it doesn't think it's worth throwing an exception if you try to write too much data...