Tuesday, September 23, 2008

Quartz.Net and Castle.Scheduler for scheduled jobs

I've had the opportunity to work with both scheduler frameworks in the same project (ended up switching out Quartz.Net for Castle.Scheduler) and here is what I found.


  1. CronTrigger alone is almost worth it. Anyone with a unix background (like me) finds this a big win.
  2. Based on a very mature Java based project so in theory it's design is well tested.
  3. Has support for supplying different Calendars (think holiday calendar, being loaded into a "job" so that it knows not to fire on your organizations particular holidays, this is nice to have in banking for example).
  4. comes with command line client and service. This wasn't out when I was using it and I had to implement my own versions.
  1. Complete Seperation of Triggers (scheduling objects) and a "JobDetail" (think name, description, etc). This in my experience lead to alot of confusion with developers and caused alot of inconsistency. Example: When wanting to reschedule a job, you had to reschedule it by it's trigger name. Which would cause problems if you had that trigger setup on more than one "JobDetail", and also would require you to find the trigger name of that job anyway.
  2. A lot of string literals. Just my personal take don't care for this.
  3. Some incomplete implementations. Example: when using 0.9.1 I had a dev who was stuck on why NextFireTime wasn't showing up on a Trigger. Some things are just tagged as not implemented yet.
  4. MegaClasses. Lots of methods, lots of noise. Again this is a port so it's not like Quartz.Net can vary too terribly much from Quartz.
  5. Only one developer that I can see. He works hard, pushes out releases frequently, but the Castle team is top notch and has many qualified contributors, it's not a fair comparison.
  6. RamJobStore was solid, ADOJobstore was a bit flakey and didn't work nearly as well.
Castle Scheduler

  1. Leverages Castle Windsor. If you use it already this is huge plus.
  2. Simple small easily understandable classes.
  3. JobSpec easy to understand and transparent to the junior devs. Includes a trigger property so that there is only a 1 to 1 mapping between triggers and jobs.
  4. SqlJob store is well supported and works about as well as the InMemoryJobStore.
  5. Out of the box clustering of schedulers using a db backend to track jobs between the schedulers.
  1. As most castle projects, may not be enough docs for less experienced devs unused to reading source code and unit tests.
  2. Limited out of the box trigger support. You'll have to implement your own triggers to get something outside of daily and interval executions.
  3. You have to be comfortable builing Castle Trunk. This is a limiter to new users obviously.

Both of them do the job if you need a job scheduler. If you already "speak Castle" and are comfortable with that tool chain then Castle.Scheduler is a much lower friction option. If you don't already use Castle (which I love btw) , or you need complex scheduling then Quartz.Net may be more for you. However, fear the AdoJobStore and prepare to use another method to persist you jobs, if you find friction using it for higher performance scenarios.

I'll try to make time showing the basic use of Castle.Scheduler not already covered in docs later in the week.

1 comment:

AlexMan said...

good comparison I remember the learning porcess on Quartz was ten times hardder than Castle. Kudos Buddy