+972 52-548-6969
Not invented here, useful noneteless
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.
Comments
What about Windows Workflow Foundation?
I would love to hear you suggestions for admin UI, what would you expect from it and on which UI platform should it run on? There has been a little discussion on Quartz.NET mailing list about porting the Java Quartz's web admin app to Quartz.NET but no real work done yet.
We are using WF for tasks which sound like these. I haven't used any of these, I would check these out. But a Workflow sometimes is a more natural way to combine these bits and pieces together into a coherent business process. If only WF designer hosting is out of the beta mode, I would suggest WF.
Oh dear. I just googled "Quartz.NET" and clicked on the first link. Opps! NSFW! The 2nd and 3rd links are more appropriate :)
I also dont like the use of the windows built in scheduling.
To that end we are currently building a scheduler automation system (load balancing, timed triggers, file triggers, email triggers) ... Thanks for the pointers, I had not done a thorough search of what is out there, although at a first glance these components dont seem to cover our needs. Hey, whats so bad with COM, it seems to play nicely, we like it :)
What is with the WF solution, I must be missing something... How does hosting the WF designer provide any scheduling automation of tasks?
I'll just add that creating a new process is a desireable feature, especially since it allows you to run tasks with different user identies (i.e., lowest-priviledge). And it makes the job of the scheduling system to shut down a runaway task (as the windows scheduler does) much easier. How did the other 2 in-process systems do this? Running them on a thread? And how do they deal with a task throwing an exception and corrupting the host process's state?
I had a bad experience with the task scheduler... I don't know how much work u plan to use it for but we used it for quite a lot of tasks that happens only once and it didn't scale. Finally we wrote a specific solution for this scenario.
John,
Yes, they run it in a thread, although a process execution is not really hard to add.
I don't believe there is a chance of a task throwing exception and corrupting the state of the scheduler, it is one of those things that they handle.
It is possible for a rogue task to do weird things to the process, like lower its priority or some such stuff, but in general, it is not really the case.
A rogue process can do much the same damage.
Note that Vista and Server 2008 come with an enhanced Task Scheduler (informally called "Task Scheduler 2.0"). It's still COM-based, but the type library is very .NET friendly - just add a reference and you're ready to whip some code.
What I liked the most about the new model is the ability to create custom task handlers, which are essentially COM DLLs hosted in the COM surrogate process (dllhost.exe). The custom task handlers feature the ability to pause, resume and stop the task at will, report progress and report task completion, making it even more useful for administrators.
By the way, the UI is much cooler too, I think admins are going to love it.
Sasha,
Yes, I noticed.
It also has a far richer semantics for the scheduling itself.
Pretty neat stuff.
Comment preview