Quartz is architected in modularized way, that's why before running it, several components need to be snapped together.
Configuration, Resource Usage and StdSchedulerFactory
Quartz is architected in modularized way, that's why
before running it, several components need to be snapped together.
Components need to be configure before Quartz :
- ThreadPool - It provides a set of
Threads to Quartz and Quartz used these Threads for executing jobs. The more
threads available in pool allows the number of jobs can run concurrently.
Some Quartz users find that they need 5 threads are enough because they have
fewer jobs at any given time, but generally all jobs are not scheduled to
execute at the same time and the jobs complete quickly. But some other users
find that they need 10,50 and 100 threads because they have some thousands
of triggers with various schedule, which can end up by around 10 and 100
jobs trying to execute at any given time. There is no any rule for finding
the size of scheduler's pool, it is only depend on what you are using for
the scheduler. Too many threads can bog down your system but make sure you
have enough threads for executing the jobs.
A ThreadPool interface is defined in the "org.quartz.spi" package. Quartz ships with a simple thread pool named
org.quartz.simpl.SimpleThreadPool. It simply maintains a fixed set of threads in its pool
that never shrinks and never grows. But it is otherwise quite robust and is very well tested - as nearly everyone using Quartz uses this pool.
- JobStore - Job Store are used to keep track
of all the "work data" that you give to the scheduler: jobs,
triggers, calendars, etc. The important step for Quartz Scheduler step is
selecting the appropriate JobStore. You declare which JobStore your
scheduler should use (and it's configuration settings) in the properties
file (or object) that you provide to the SchedulerFactory that you use to
produce your scheduler instance.
- DataSource - JDBCJobStore can get the
connections to your database by setting up a DataSource. In Quartz
properties DataSource can be defined in different approaches. One approach
is, Quartz can create and manage the DataSource itself through providing the
all connection information to the database. And another approach is,
DataSource is used by Quartz which is managed by an application server that
Quartz is running inside of - by providing JDBCJobStore the JNDI name of the
- Scheduler - Finally, you need to create the
instance of your Scheduler. Now 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
the Scheduler should create itself as an RMI server object, what host and port to use, etc.. StdSchedulerFactory
can create Scheduler instances that are actually proxies (RMI stubs) to Schedulers created in remote processes.
StdSchedulerFactory is a class, that is implementation
of org.quartz.SchedulerFactory interface and does all of its work of creating a
Quartz Scheduler instance based on the content of properties file. Generally, properties are
stored in and loaded from a file, but can also be created by your program and handed directly to the factory.
Simply invoking getScheduler() on the factory you get the instance of scheduler.
DirectSchedulerFactory is a class, that is singleton
implementation of SchedulerFactory interface. It is useful for those user that
want to create their Scheduler instance in more programatic way. Generally, it
can be used for the following reasons: (1) it requires the user to have a greater understanding of what they're
doing (2) it does not allow for declarative configuration - or in other words, you end up hard-coding all of the scheduler's settings.
"org.apache.commons.logging" framework is
used by Quartz for its logging needs. Quartz does not produce so much logging
information, it produce some information during initialization and then messages
about serious problems while jobs are executing.