Quartz是以标准组件的方式组织的,所以,使它运行起来,一些组件需要被联合起来。
在Quartz能够工作之前,需要配置的主要组件有:
在运行jobs时,线程池为Quartz提供了一系列的线程。在线程池里的线程越多,能够并行执行的jobs就越多。但是,太多的线程会使系统瘫痪。大部分的Quartz用户发现,5个线程就足够了-因为他们在指定时间里只有少于100的jobs,这些jobs并不都是在同一时刻执行,jobs完成得也很快的。其他的用户发现他们需要10、15、50或者100个线程-因为他们在不同的调度器里用了上万个触发器,在给定的时间里,平均在10到100个jobs试着执行。为调度器找到合适的线程数量完全依赖于你用调度起来做什么。不在乎线程数量,而要确保你有足够的线程来使jobs执行。如果一个触发器的触发时间到来了,可是没有一个能够用的线程,Quartz将会等到可用线程的来临,然后job将会在几毫秒后执行。这可能会引起不触发-如果不在属性文件里给调度器配置“misfire threshold”的话。
线程池接口是在org.quartz.spi包里定义的,你能够创建一个线程池以自己的方法。Quartz装配了一个简单(但是很好的)的线程池,是org.quartz.simpl.SimpleThreadPool。这个线程池简单的维护一些在池里固定的线程-不会增加也不会减少。但是它能够做很多事而且经过测试了的,几乎每个Quartz用户用这个线程池。
JobStores 和
DataSrouces在前面讨论过了,这里值得一提的是,所有JobStores都实现了org.quartz.spi.JobStore接口,如果在打包里的任何一个JobStore不能够满足你的需求的话,你可以自己做一个。
最后,你需要创建你的
Scheduler实例。Scheduler需要提供他的名称,说明RMI的设置,处理JobStore和ThreadPool的实例。RMI设置包括调度器是否作为一个RMI服务器而创建。StdSchedulerFactory也能够产生调度器的实例,这些实例实际上是创建在远程进程中的调度器代理(RMI桩)。
StdSchedulerFactory
StdSchedulerFactory实现了org.quartz.SchedulerFactory接口。它用了一系列的属性(java.util.Properties)来创建和初始化一个Quartz的调度器。这些属性通常保存和加载在一个文件里,但是也可以通过你的程序创建直接交给工厂处理。在工厂上调用getScheduler()就可以产生调度器,初始化它(还有线程池,JobStore和数据源),然后返回一个句柄到这个公共的接口。
// 默认调度器是quartz.propeties文件定义的,这个文件可以在当前目录下找到,也可以在//classpath里找到,如果都找不到了,就用quartz.jar里的quartz.propeties文件。
SchedulerFactory sf = new StdSchedulerFactory();
Scheduler scheduler = sf.getScheduler();
scheduler.start();
用指定的属性对象初始化:
SchedulerFactory sf = new StdSchedulerFactory();
sf.initialize(schedulerProperties);// schedulerProperties是属性对象
Scheduler scheduler = sf.getScheduler();
scheduler.start();
用指定的属性文件初始化:
SchedulerFactory sf = new StdSchedulerFactory();
sf.initialize(fileName);//属性文件全名
Scheduler scheduler = sf.getScheduler();
scheduler.start();
DirectSchedulerFactory
DirectSchedulerFactory是另外的一个SchedulerFactory实现。在更多的编程方法里创建调度器时,他很有用。他的用法不被赞成,原因有:1.它需要用户更清楚的知道他们在做什么。2.它不允许配置,就是说,你必须要在代码里配置所有的调度器属性。
Logging
Quartz给它所有需要的日志是使用org.apache.commons.logging框架的。Quartz没有产生很多的日志信息。仅有一些在初始化时关于一些jobs正在执行的问题的信息。为了调整日志设置,我们需要了解Jakarta Commons Logging框架,超过了本文档讨论的范围。