Not invented here, useful noneteless

time to read 3 min | 579 words

image I mentioned before that we built most of the batch processes without ever considerring how we would actually run them. We put a tiny bit of thought into what we would need, and built declerative attributes that specified what we wanted.

We also expressed that in terms that are not tied to a particular scheduling platform, but in terms that made sense to us. For instance, we have tasks that are scheduled for "Morning", and that specifies that they should not run in holidays.

Since it became clear that we now really need to suppose some way of scheduling those for real (you know, we are going to production, and I understand that admins are getting pissed if they have to run debuggers in 2:32AM sharp in order to get things to work).

So, I looked at four options:

  • Castle.Components.Scheduling
  • Quartz.NET
  • Rhino Scheduling
  • Task Manager

Both Castle.Component.Scheduling and Quartz.NET are very rich scheduling platform, with a lot of options and hooks and some really nice code under the seams. Quartz.NET seems to be the more mature, and it has a lot more options. If I wanted to build a system where scheduled tasks and batch processes were the main thing, I would likely take one of those, and most probably Quartz.NET.

The problem with both of them is that they have no easy way for an administrator to manage those, and while it is probably very easy to built, that is not what I consider a good investement of my time. At least not in comparision to the several dozens tasks that I have to manage.

Rhino Scheduling has the sever problem of not existing, and while I built task scheduling application in the past, just looking at what the previous two have done was enough to make me feel inadeque. I was certainly not going to go off and implement a misfire feature, that was for sure.

That left Task Scheduler. I had dealt with it only manually in the past, so I was very skeptic. It is COM based thingie, and I don't like COM based thingies. They like to throw HRESULT around and puke INVALID_WRPC errors all over the place.

Nevertheless, it looked like my manager has already had a managed library to deal with it, and using that, it was extremely easy to start exploring what Task Scheduler had to offer. I have to say, I came away impressed. It has a very rich set of scheduling semantics. Not nearly as full featured as the first two on the list, but fairly comprehensive. Certainly enough for my needs. I particularily liked te OnIdle and the MonthlyDOW (although I am pissed about not being able to schedule to the first and last Sundays of March on the same trigger).

The major advantage is that we can rely on the existing infrastructure, and the admin should probably know it and be able to deal with it easily.

For my part, I don't touch the UI, it is API very similar to Quartz.NET, you register a task and a trigger, and set it loose. The major difference is that Task Scheduler does it by shelling out a new process, while most of the others use a command pattern to do it in process.

For my purposes, creating a new process is just fine, and the builtin UI is a significant benefit.