Quartz Enterprise Job Scheduler 1.x Tutorial---Reprint

Lesson 10:configuration, Resource Usage and Schedulerfactory

Http://www.quartz-scheduler.org/documentation/quartz-1.x/tutorials/TutorialLesson10

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, need to being configured before Quartz can do it work is:

• ThreadPool
• Jobstore
• DataSources (if necessary)
• The Scheduler itself

TheThreadPool provides a set of Threads for Quartz and 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 5 or so threads is plenty-because they has fewer than jobs at any given time, the jobs is not generally scheduled to run at the same time, and the jobs is short-lived (complete quickly). Other users find that they need, the ten or even threads-because they has tens-of-thousands of triggers with vari OUs Schedules-which end up has a average of between and jobs trying to execute on any given moment. Finding the right, size for your scheduler's pool is completely dependent on what you ' re using the scheduler for. There is no real rules, other than to keep the number of threads as small as possible (for the sake of your machine ' s res ources)-but do sure you had 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 would block (pause) until a thread comes available, then the Job would execute-some number of milliseconds later than it should have. This could even cause the tread to misfire-if there are 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 can create a ThreadPool implementation Like. Quartz ships with a simple (but very satisfactory) thread pool named Org.quartz.simpl.SimpleThreadPool. This ThreadPool simply maintains a fixed set of the threads in its pool-never grows, never shrinks. But it's otherwise quite robust and is very well tested-as nearly everyone using Quartz uses this pool.

jobstores and datasources were discussed in Lesson 9 of this tutorial. Worth Noting here, are 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 and then you can make your own.

Finally, you need to create your Scheduler instance. The Scheduler itself needs to is 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 an RMI server object (make itself available to Remo TE connections), what the host and port to use, etc. Stdschedulerfactory (discussed below) can also produce Scheduler instances that is actually proxies (RMI stubs) to schedu Lers created in remote processes.

Stdschedulerfactory

Stdschedulerfactory is an implementation of the Org.quartz.SchedulerFactory interface. It uses a set of properties (Java.util.Properties) to create and initialize a Quartz Scheduler. The properties is generally stored in and loaded from a file, but can also is created by your program and handed directly to the factory. Simply calling Getscheduler () on the factory would produce the scheduler, initialize it (and its ThreadPool, Jobstore and D Atasources), and return a handle to their public interface.

There is some sample configurations (including descriptions of the properties) in the "Docs/config" Directory of the Quar TZ distribution. You can find all documentation in the "Configuration" manual under the "Reference" section of the Quartz Documentatio N.

Directschedulerfactory

Directschedulerfactory is another schedulerfactory implementation. It is useful to those wishing to create their Scheduler instance in a more programmatic the. The generally discouraged for the following reasons: (1) It requires the user has a greater understanding of WH At they ' re doing, and (2) it does isn't allow for declarative configuration-or in other words, you end up hard-coding all Of the scheduler ' s settings.

Logging

Logging

Quartz uses the SLF4J framework for all of its logging needs. In order to "tune" The logging settings (such as the amount of output, and where the output goes), you need to understand The SLF4J framework, which is beyond the scope of this document.

If you want-to-capture extra information about trigger firings and job executions, your may is interested in enabling the org.quartz.plugins.history.loggingjobhistoryplugin and/or Org.quartz.plugins.history.LoggingTriggerHistoryPlugin.

Quartz Enterprise Job Scheduler 1.x Tutorial---Reprint