Lesson 10: Configuration, Resource Usage and SchedulerFactory

http://www.quartz-scheduler.org/documentation/quartz-2.2.x/tutorials/tutorial-lesson-10.html

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:

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

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 5 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 10, 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) - but 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 very satisfactory) thread pool 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 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, 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, then you can make 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, etc.. StdSchedulerFactory (discussed below) can also produce Scheduler instances that are actually proxies (RMI stubs) to Schedulers 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 are generally stored in and loaded from a file, but can also be created by your program and handed directly to the factory. Simply calling getScheduler() on the factory will produce the scheduler, initialize it (and its ThreadPool, JobStore and DataSources), and return a handle to its public interface.

There are some sample configurations (including descriptions of the properties) in the “docs/config” directory of the Quartz distribution. You can find complete documentation in the “Configuration” manual under the “Reference” section of the Quartz documentation.

DirectSchedulerFactory

DirectSchedulerFactory is another SchedulerFactory implementation. It is useful to those wishing to create their Scheduler instance in a more programmatic way. Its use is generally discouraged for the following reasons: (1) it requires the user to have a greater understanding of what they’re doing, and (2) it does not allow for declarative configuration - or in other words, you end up hard-coding all of the scheduler’s settings.

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, you may be interested in enabling the org.quartz.plugins.history.LoggingJobHistoryPlugin and/ororg.quartz.plugins.history.LoggingTriggerHistoryPlugin.

    Quartz框架的结构是模块化的，因此它运行的几个组件需要“咬合”在一起。幸运的是，一些帮助类可以完成这些工作。

       在Quartz可以工作之前需要配置的几个主要组件：

·        ThreadPool

·        JobStore

·        DataSources (if necessary)

·        The Scheduler itself

         ThreadPool提供一组线程给Quartz执行作业任务时使用。池里有越多的线程，能并发执行的作业任务数量就越多。然而，太多的线程可能会导致系统挂死。大多数Quartz用户发现大约5个线程是比较合适的——在任何时候作业任务数都小于100，所有的作业任务一般不会在同一个时间被调度，并且作业任务生命周期短（很快就能完成）。其他人认为他们需要10，15，50甚至100个线程——他们有成千上万个触发器用于各种各样的调度——最后在任何时候都是平均在10到100个作业任务同时执行。寻求调度线程池正确的大小完全依赖于你使用什么样的调度。这里没有固定的规则，而是保留尽可能少的线程浸透（为了你的计算资源）——但是要确保有足够的线程让作业任务准时起动。注意如果触发器要触发的时间到了，但是没有可用的线程，Quartz会让该触发器阻塞直到有可用的线程，然后作业任务才会执行——这样会比本应该执行的时间延迟几毫秒。这里有可能会导致触发失败——如果在Quartz配置的“misfire threshold”期间一直没有可用的线程。

         ThreadPool接口在包org.quartz.spi内定义，你可以用任何方式创建ThreadPool的实现类。Quartz附带了一个简单的线程池名为org.quartz.simpl.SimpleThreadPool（但是也能满足需要）。这个线程池简单包含固定数量的线程数——不会增加，也不会减少。但是它在其他方面特别健壮，并且经过很好的测试——几乎每个使用Quartz的人都用这个线程池。

         JobStores和数据源在教程中的第九课讨论过。这里需要注意，事实上所有的JobStores都实现org.quartz.spi.JobStore接口，如果这些JobStores没有一个适合你的需要，你可以自行开发一个。

       最后，你需要创建一个调度器实例。该实例需要指定一个名字，告知它RIM的设置和持有的JobStore和ThreadPool实例。RMI设置包括调度器是否作为RMI服务对象（设置允许远程连接），并设置连接的主机名和端口号等。StdSchedulerFactory（下面将讨论）也可以产生调度器实例，实际上是代理RMI端在远程进程中创建调度器实例。

 

StdSchedulerFactory

         StdSchedulerFactory是org.quartz.SchedulerFactory接口的实现类。它使用一组参数（java.util.Properties）来创建和初始化Quartz调度器。这些参数一般存储在文件中，并且从文件中加载，也可以直接在程序中创建直接赋值给工厂类。在工厂类中简单地调用getScheduler方法就能创建和初始化调度器对象（包括它的ThreadPool，JobStore和数据源），并返回一个引用（也叫句柄）到它的公共接口。

       在Quartz发布包的“docs/config”目录里有一些示例配置（包含参数说明）。你可以在Quartz文档的参考板块下的配置手册里找到完整的文档。

 

DirectSchedulerFactory

         DirectSchedulerFactory是另一个SchedulerFactory实现类，它适用于希望用更多的编程方式创建调度器实例。一般不鼓励使用它主要有以下原因：（1）它要求使用都对他们想做的事情有比较深的理解，（2）它不允许声明式配置，换句话说，你必须编写代码来完成调度器的所有参数设置。

Logging

         Quartz选用SLF4J框架来满足所有的日志需求。为了“调整”日志设置（例如日志输出量，日志输出位置），你需要去了解SLF4J框架，这个框架不在此文档内。

    如果你想了解触发器触发和作业任务执行的额外信息，你可能会对org.quartz.plugins.history.LoggingJobHistoryPlugin和/或org.quartz.plugins.history.LoggingTriggerHistoryPlugin感兴趣。