Without running this code, what would you expect this to do?

public class Strange
{
    [ThreadStatic]
    public /* static */ int Value;
}

var s1 = new Strange {Value = 1};
var s2 = new Strange { Value = 2 };

Console.WriteLine(s1.Value);
Console.WriteLine(s2.Value);

ThreadPool.QueueUserWorkItem(state =>
{
    Console.WriteLine(s1.Value);
    Console.WriteLine(s2.Value);
});

Can you guess?

There are some things that I just don’t get. The new MS Courier is one such thing. Check the link, this is basically a book size iPhone/tablet.

Go checkout the video, you’ll notice something that will kill this device.

It uses a pen, to write!

Leaving aside the fact that no OCR program has yet been able to figure out what I am writing (including the one in my brain), using a pen it annoying.

I write about three to four times as fast using a keyboard than using a pen (and I can use both hands). And I don’t write, using archaic pen & paper, much at all. That affect my writing readability when I am using a pen, of course, leading to a feedback cycle.

This pretty much turn me off of the device completely.

I got all of the following during a recent support call to deal with a hard server crash:

• I have never seen something like that before.
• Our internal tools crash when they connect to your servers.
• We are probably not going to recover this server.
• You do have a backup, right?

Thankfully, it turned out to be something stupid that was fixed very quickly. But it sure was scary.

Just run NH Prof through a stress test to see how well it handles scenarios where you just throw data at it.

I run into a few interesting bugs (mostly related to threading), which were luckily simple enough to handle.

The end result was:

Which is pretty impressive, I think. Just to give you an idea, we used to test NH Prof against the NHibernate integration test suite, which isn’t even half of what I threw at it now.

There is a small problem, however, the profiled application is capable of outputting data faster than NH Prof can process it. That means that unless there are some rest periods, NH Prof is in somewhat of a problem here, because it will never catch up.

I’ll post some more about how we can solve this.

I recently run into a convoy situation in NH Prof. Under sustained heavy load (not a realistic scenario for NH Prof), something very annoying would happen.

Messages would stream in from the profiled application faster than NH Prof could process them.

The term that I use for this is Convoy. It is generally bad news. With NH Prof specifically, it meant that it would consume larger and larger amounts of memory, as messages waiting to be processed queued up faster than NH Prof could handle them.

NH Prof uses the following abstraction to handle queuing:

public interface IQueue<T>
{
    void Enqueue(T o);
    T Dequeue();
    bool IsEmpty { get; }
}

Now, there are a few things that we can do to avoid having a convoy. The simplest solution is to put some threshold on the queue and just start dropping messages if we reached it. NH Prof is actually designed to handle such things as interrupted message stream, but i don’t think that this would would be nice thing to do.

Another alternative would be write everything to disk, so we don’t have memory pressure and can handle much larger queue sizes. The problem is, of course, that this requires something very subtle. T now must be serializable, and not just T, but everything that T references.

Oh, Joy!

This is one of the cases where just providing the abstraction is not going to be enough, providing an alternative implementation means having to touch a lot of other code as well.

As someone who does a lot of Open Source stuff, I find myself in an interesting position in the CodePlex Foundation mailing list. I am the one who keep talking about letting things die on the vine if they aren’t successful on their own.

I am going to try to put a lot of discussion into a single (hopefully) coherent post. Most of the points that I am going to bring up are from the point of view of an OSS project that got traction already (has multiple committers, community, outside contribution).

One of the oft repeated themes of the conversation in the CPF mailing list is that the aim is to encourage OSS adoption and contributions to OSS in businesses and corporations.

That sounds nice, but I don’t really get why.

From the business side: if a business don't want to use OSS, then it is in a competitive disadvantage compared to its competitors that do make use of it, since OSS projects tend to make great infrastructure and generate high quality base to work from. If you choose to develop things in house it is going to cost you a lot. And you are likely going to end up with an inferior quality solution.

This is not to disparage someone’s effort, but a OSS project that got traction behind it is likely to have a lot more eyes & attention on it than a one off solution. The Java side has demonstrated that quite clearly.

Even in the .Net world, I can tell you that I am aware of Fortune 50 companies making use of things like NHibernate or Castle. They can most certainly fund building a project of similar size, but it doesn’t make economic sense to do so.

From the project side, if you got enough traction, you don't generally worry about the OSS fearing businesses. It is their loss, none for the project.

It would be more accurate that the project won't feel any pain if a business decide not to use it. Remember that unlike commercial software, OSS projects don't really have an incentive to "sell" more & more.

There is the incentive to grow bigger (for ego reason, if nothing else), get more people involved, add more features, etc. But unless there is some business model behind it (and in the .NET world, there are very few projects with a business model behind them), growing the project usually mean problems for the project team.

As a simple example, Rhino Mocks mailing list has an average of 140 messages per month. I had to scale down my own involvement in the mailing list because it took too much of my time. The NHibernate Users mailing list is crazy, averaging in a thousand messages a month this year alone.

That is even assuming that I want traction for a project, which isn’t always the case. As a good example, I have a lot of stuff that I put out as one-use only solutions. Rhino Igloo is a good example of that, a WebForms MVC framework that we needed for a single project. I built it as OSS, we get contributions for it once in a while. But if it gets to be *very* active, I am going to find myself in a problem, because I don't really want to maintain it anymore.

But in general, for most projects I do want to have more contributors. In the CPF mailing list the issue of getting contributions from companies was brought up as problematic. I disagree, since I don't find that the problems that were brought up (getting corporate and legal sign up for contributing work, getting people to adopt OSS for commercial uses) has any relevance whatsoever to getting more contributors. By far, most contributions that we get for the projects I am involved at are from people making commercial use of them.

But usually, I don’t really care about adoption.  I have 15 - 20 OSS projects that I have either founded or am a member of, in exactly one of them I cared about adoption (Rhino Mocks), and that was 5 years ago, mainly because I thought it would give me some credentials when I was looking for a job (and it did).

For all the rest, I am working on those because I need them to solve a problem. I get the benefit that other people are going to look at them and contribute if they feel like it, but mostly, I am working on OSS to solve a problem, the number of users in a project isn't something that I really care about.

There were three scenarios that were discussed in the mailing list that I want to address in particular.

A company would like to pay you 5 times your normal rates, but they have a “no OSS” policy, thus losing the contract.

I have to say that this scenario never happened to me.  Oh, I had to talk with the business a lot of time. It is easy to show them why OSS is the safer choice.

Today, that is fairly easy. I can point out stats like this: http://www.ohloh.net/p/nhibernate and that trying to build something like NH is going to cost you in the order of 130 years and ~15 millions dollars. I can tell them that going with MS data access method is a good way to throw good money at upgrading their data access methodology every two years. I can point them to a whole host of people making good use of it.

I got lots of arguments to use. And they tend to work, quite well, in fact. I may need to talk to the lawyers, but that has generally been a pretty straightforward deal.  So no, I don't lose clients because of no OSS rule.

Beside, you know what, if they are willing to pay me 5 times my normal rate, I am going to be very explicit about making my preferences made and explaining the benefits. Afterward, they are the client, if they want to may me gobs of money, I am not going to complain even if I am going to use NIH as the root namespace.

Corporate developers have a problem getting permission to use OSS projects in their product or project.

I have seen it happen a few times in the past, but it is growing rarer now. The main problem was never legal, it was the .NET culture more than anything else. The acceptance of OSS as a viable source of software had more to do with team leads and architects accepting that than any legal team putting hurdles in the path.

Oh, you still need to talk to legal before, but you are going to do that when bringing a 3rd party component anyway. (You do make sure to run any commercial legal agreements through the legal department, right? You need to know that there aren’t hooks involved there).

Corporate developers have a problem getting permission to contribute to OSS projects.

Once OSS is adopted, I never run into an issue where legal stopped the contribution of a patch. There are damn good reasons for the business to want this, after all.  To that manager, I am going to say: "look, we can maintain it, or we give it to the project, they maintain/fix/debug/improve it. we get great credits and we gain a lot for work we would have done anyway"

A few final thoughts, OSS projects are a dime a dozen. In the .Net space alone there are thousands. Most of them, I have to say, aren’t really that interesting. Out of those thousands of projects, there are going to be a few that would get traction, attract additional committers, outside contributions and a community.

I think it would be safe to say that there are around fifty such projects in the .Net space. There is nothing particularly noble or important in an OSS project that requires special treatment. If it gets enough attention, it will live on. If it doesn’t, who cares (except maybe the author)?

The CodePlex Foundation, however it may end up as, is going to be dealing with the top fifty or so projects, simply because trying to reach the long tail of OSS projects is a futile task. I mentioned what I think would be good ways of helping the top projects (resources, coaching, money).

Another approach would be to turn it around, the CPF can focus on building a viable business model for OSS projects. A healthy OSS project is one that makes money for the people who contribute to it. It may be directly or indirectly, but if it isn’t going to do that, it isn’t going to live long. A labor of love would keep one or two committers working on a project, but it wouldn’t generally sustain a team.

Finally, something that I think seems to get lost in all the noise around it, Open Source projects are about the code. I hear a lot about legal issues, making business adopt OSS, etc. I don’t see discussion about the main thing.

Show me the code!

One of the warning signs for bad multi threaded code is calling code that you don’t own while holding a lock. I just discovered a bug in NH Prof that is related to just that issue.

But I wasn’t really stupid, and the story of this bug is a pretty interesting one.

Let us look at what happened. I have a deadlock in the application, where two threads are waiting for one another. In the UI thread, I have:

And on a background thread, I have:

This is actually code that happen in two separate classes. And it sounded very strange, until I walked up the stack and found:

All nice and tidy, and it looks good. Except that Sessions.Add invoke the SessionsCollectionChanged, which perform a block UI call, while the UI is trying to enter a lock that is currently being held.

Like I said, this is a classic threading issue, but it is pretty hard to see, unless you can actually get the stack trace.

I don’t have a lot of patience for repeated bugs. I just got a bug report that turn out to be in the result of the same feature as a previous bug I fixed.

I could have fixed the bug. But I didn’t bother. A repeated bug in the same area for the same reason usually indicate a fragile design. In this particular case, the feature wasn’t important, so I just ripped it all out, root & branch.

If it was important, I would have still ripped the whole thing apart, and then I would rebuild it from scratch, using a different design.

Fragile designs are one of the worst enemies that you can have, they will keep dropping things in your lap until you finally fix them once and for all. And I find that usually just starting from scratch on a feature implementation is the best way of doing that.

Recently we got a bug report about the performance of Windsor when registering large number of components (thousands). I decided to sit down and investigate this, and found out something that was troublesome.

Internally, registering a component would trigger a check for all registered components that are waiting for a dependency. If you had a lot of components that were waiting for dependency, registering a new component degenerated to an O(N^2) operation, where N was the number of components with waiting dependencies.

Luckily, there was no real requirement for an O(N^2) operation, and I was able to change that to an O(N) operation.

Huge optimization win, right?

In numbers, we are talking about 9.2 seconds to register 500 components with no matching dependencies. After the optimization, we dropped that to 500 milliseconds. And when we are talking about larger number of components, this is still a problem.

After optimization, registering 5,000 components with no matching dependencies took 44.5 seconds. That is better than before (where no one has the patience to try and figure out the number), but I think we can improve up it.

The problem is that we are still paying that O(N) cost for each registration. Now, to suppose systems that already uses Windsor, we can’t really change the way Windsor handle registrations by default, so I came up with the following syntax, that safely change the way Windsor handles registration:

var kernel = new DefaultKernel();
using (kernel.OptimizeDependencyResolution())
{
    for (int i = 0; i < 500; i++)
    {
        kernel.AddComponent("key" + i, typeof(string), typeof(string));
    }
}

Using this method, registering 5,000 components drops down to 2.5 seconds.

I then spent additional time finding all the other nooks and crannies where optimizations hid, dropping the performance down to 1.4 seconds.

Now, I have to say that this is not linear performance improvement. Registering 20,000 components will take about 25 seconds. This is not a scenario that we worry over much about.

The best thing about the non linear curve is that for a 1,000 components, which is what we do care about, registration takes 240 milliseconds. Most applications don’t get to have a thousand components, anyway.

There are also other improvements made in the overall runtime performance of Windsor, but those would be very hard to notice outside of a tight loop.

The NHibernate scene is growing bigger.

I am starting to see NHibernate related jobs crossing me mailbox, NHibernate 2.1 downloads crossed the 20,000 downloads a while ago and a very active mailing list.

iMeta, who sponsored the development of the AST based parser and is currently sponsoring the Linq for NHibernate effort, is now also offering Commercial Support for NHibernate.

This is a separate offer from mine, and seems to be targeting a different audience.

From my point of view, the more the merrier, it simply shows that the market for NHibernate is growing, fast.