How-To: Use Multiple (Non-Clustered) Schedulers

For managing resources, for example, if you have a mix of light-weight and heavy-weight jobs, then you might want to have a scheduler with many threads to service the lightweight jobs and one with few threads to service the heavy-weight jobs. Doing this would keep your machine’s resources from being overwhelmed by running too many heavy-weight jobs concurrently.

Note that you can create as many schedulers as you like within any application, but they must have unique scheduler names (typically defined in the quartz.properties file). This means that you'll need to have multiple properties files, which means that you'll need to specify them as you initialize the StdSchedulerFactory (as it only defaults to finding "quartz.properties").

If you run multiple schedulers they can, of course, each have distinct characteristics. For example, one might use RAMJobStore and have 100 worker threads, and another might use JDBC-JobStore and have 20 worker threads.

Important:

Never start (scheduler.start()) a non-clustered instance against the same set of database tables that any other instance with the same scheduler name is running (start()ed) against. Doing so will cause data corruption and erratic behavior.

Note:

The following information applies to JDBC-JobStore. You might also want to look at RMI or JMX features to control a scheduler in a remote process, which works for any JobStore. Additionally, you might want to look at the Terracotta Quartz Where features.

Currently, if you want particular jobs to run in a particular scheduler, then it needs to be a distinct scheduler, unless you use the Terracotta Quartz Where features.

Suppose you have an application "App A" that needs to schedule jobs (based on user input) that need to run either on the local process/machine "Machine A" (for simple jobs) or on a remote machine "Machine B" (for complex jobs).

It is possible within an application to instantiate two (or more) schedulers, and schedule jobs into both (or more) schedulers, and have only the jobs placed into one scheduler run on the local machine. This is achieved by calling scheduler.start() on the scheduler(s) within the process where you want the jobs to execute. Scheduler.start() causes the scheduler instance to start processing the jobs (that is, start waiting for trigger-fire times to arrive, and then executing the jobs). However a non-started scheduler instance can still be used to schedule (and retrieve) jobs.

In "App A" create "Scheduler A" (with config that points it at database tables prefixed with "A"), and invoke start() on "Scheduler A". Now "Scheduler A" in "App A" will execute jobs scheduled by "Scheduler A" in "App A."

In "App A" create "Scheduler B" (with config that points it at database tables prefixed with "B"), and DO NOT invoke start() on "Scheduler B". Now "Scheduler B" in "App A" can schedule jobs to run where "Scheduler B" is started.

In "App B" create "Scheduler B" (with config that points it at database tables prefixed with "B"), and invoke start() on "Scheduler B". Now "Scheduler B" in "App B" will execute jobs scheduled by "Scheduler B" in "App A".