CDV ❯ Support Quartz Job Scheduler

• Type: New Feature
• Status: Closed
• Priority: 2 Major
• Resolution: Duplicate
• Component/s: DSO:L1
• Labels:

• Assignee: drb
• Reporter: drb
• Created: November 30, 2006
• Votes: 0
• Watchers: 1
• Updated:

  July 27, 2012
• Resolved:

  April 22, 2007

Description

Support clustering of Quartz:

* Request came from a couple of sources including Rob Harrop (cofounder of Interface21). I think the primary requirements are:

* 1. Availaiblity:
            + Cluster the job schedules (so machine hosting job schedule is not SPOF)
            + Machine excuting job is not SPOF - i.e. master restarts work when node recovers.
* 2. JobPersistence:
            + Replace RAMJobStore with DSO based implementation: This allows the scheduling engine to work without a database. "RAMJobStore is the simplest JobStore to use, it is also the most performant (in terms of CPU time). RAMJobStore gets its name in the obvious way: it keeps all of its data in RAM. This is why it's lightning-fast, and also why it's so simple to configure. The drawback is that when your application ends (or crashes) all of the scheduling information is lost - this means RAMJobStore cannot honor the setting of "non-volatility" on jobs and triggers. For some applications this is acceptable - or even the desired behavior, but for other applications, this may be disasterous."
* 3. Transactions:
            + Quartz can participate in JTA transactions. We can't support now, but another data-point around that.
* 4. Monitoring:
            + Cluster-wide monitoring and Stats.

Comments

Nathaniel Harward 2007-04-22

Superseded by CDV-53. Probably this issue should have been updated instead of creating a new one, but oh well :)