The architecture of Quartz is modular, and therefore to get it running several components need to be "snapped" together. Fortunately, some helpers exist for making this happen.

The major components that need to be configured before Quartz can do its work are:

The ThreadPool provides a set of Threads for Quartz to use when executing jobs. The more threads in the pool, the greater number of jobs that can run concurrently. However, too many threads may bog-down your system. Most Quartz users find that five or so threads are plenty. Because they have fewer than 100 jobs at any given time, the jobs are not generally scheduled to run at the same time, and the jobs are short-lived (complete quickly).

Other users find that they need 15, 50 or even 100 threads, because they have tens-of-thousands of triggers with various schedules, which end up having an average of between 10 and 100 jobs trying to execute at any given moment.

Finding the right size for your scheduler's pool is completely dependent on what you're using the scheduler for. There are no real rules, other than to keep the number of threads as small as possible (for the sake of your machine's resources). However, you want to make sure you have enough for your jobs to fire on time. Note that if a trigger's time to fire arrives, and there isn't an available thread, Quartz will block (pause) until a thread comes available, then the Job will execute some number of milliseconds later than it should have. This may even cause the thread to misfire if there is no available thread for the duration of the scheduler's configured "misfire threshold".

A ThreadPool interface is defined in the org.quartz.spi package, and you can create a ThreadPool implementation in any way you like. Quartz ships with a simple (but satisfactory) ThreadPool named org.quartz.simpl.SimpleThreadPool. This ThreadPool simply maintains a fixed set of threads in its pool - never grows, never shrinks. But it is otherwise quite robust and very well tested. Nearly everyone using Quartz uses this pool.

JobStores and DataSources are discussed in Working with JobStores. Worth noting here, is the fact that all JobStores implement the org.quartz.spi.JobStore interface, and that if one of the bundled JobStores does not fit your needs, you can create your own.

Finally, you need to create your Scheduler instance. The Scheduler itself needs to be given a name, told its RMI settings, and handed instances of a JobStore and ThreadPool. The RMI settings include whether the Scheduler should create itself as a server object for RMI (make itself available to remote connections), what host and port to use, and so forth. StdSchedulerFactory (discussed below) can also produce Scheduler instances that are actually proxies (RMI stubs) to Schedulers created in remote processes. For more information about the StdSchedulerFactory, see Scheduler Factories.