On several projects, I have found need of a robust in-process job scheduler for .Net with support for clustering and persistence. These last two requirements have always been a bit of a problem. What do you do when your service has been distributed across multiple machines for load-balancing and redundancy? What do you do when your service shuts down and some of its scheduled processing may or may not have been performed but you need to ensure it doesn't accidentally run a second time?
I encountered these requirements yet again a few weeks ago. Figuring this problem ought to have been solved a hundred times over by the community, I went hunting for existing solutions and eventually found Quartz.Net. Unfortunately, it does not yet support clustering or persistence like its progenitor Quartz from the Java world. Even more discouraging, after an hour or two spent reading the documentation and perusing the source, I realized that I simply was not going to be able to contribute the necessary features and adapt the framework to my needs in the time I had available. So with reluctance I launched my own scheduler project.
The scheduler provides all the basic operations and supports clustering and persistence just like I needed. It's designed as a collection of services that can be easily snapped together using an Inversion of Control container like Castle Windsor or with just a few lines of code as part of your application's initialization process. The scheduler is fairly basic but it does what I need. I have a high degree of confidence in the implementation thanks to a comprehensive suite of unit tests.
A few people have already proposed contributions to add management facilities, a pre-cooked standalone scheduler agent, job queuing, job history, and an alternative ActiveRecord-based job store. Any ideas?
More details over here: Castle.Components.Scheduler.
2 comments:
Just a nice to know: How long did it take you to write the scheduler?
:-)
Hmm. I guess about a week including later improvements to the build scripts, tests, and documentation to make it release-worthy. Hard to say because I was working on several other things at the same time.
At the time I felt more confident developing a perfect-fit solution to my current problem than uncertainly trying to contribute the necessary improvements to Quartz.Net without the benefit of any existing unit tests to back me up. But in any case, I obtained a robust and working solution when I needed it so the gamble seems to have paid off.
The nice thing about the scheduler component was that it was relatively simple and self-contained. Of course there are a lot of nice to have items still on the TODO list. Whether they materialize will largely depend on interest in the community. At this time, I have not really invested much effort in promoting the component and fostering a community.
Post a Comment