最近同事向我报怨说:选用的作业调度框架Quartz不稳定,具体规律表现为分奇偶次调度,比如第一次可以调度,第二次就不能调度了,依次类推。
我建议说:最不济办法采用先删除后添加调度信息方式应该可以。
他说:试过了,故障依旧。
。。。。。。有这种事?
小平同志说:实践是检验真理的唯一标准。
按我同事要求的方法我如法炮制一番,现象和结论竟然与他说的一样一样的,这令我大跌眼镜。
Quartz是比较成熟的开源作业调度框架,除了这个JAVA版本,还有一个.NET版本呢,怎么会有这么大BUG呢?不可能!一定是我们哪个地方没处理好。
凡事讲究证据才会令人信服,不然会沦落为被人掷鞋的小布什^_^
通过一番仔细观察取证,我发现:
1、当qrtz_fire_triggers(以qrtz_为前缀是quartz系统表,下同)表中有该任务正在执行,此时就是采用先删后加方式进行调度,她也会删除qrtz_fire_triggers中那个任务,同时,也会把
qrtz_triggers表中该任务状态置为BLOCKED(堵塞),这样该任务当然不会被触发。
2、当qrtz_fire_triggers表中没有该任务正在执行,此时就是采用先删后加方式进行调度,该任务就会立即触发。
3、当qrtz_triggers表中该任务状态是BLOCKED时,手动修改qrtz_triggers表中该任务状态为WAITINNG,该任务也会立即触发。
原来一直以为调用其API中new JobDetail()方法就会自动往qrtz_job_details写一条数据,调用其API中new trigger()方法就会自动往qrtz_triggers表里写一条数据。事实并非如此,调用sched.scheduleJob(jobDetail, trigger)时才会自动往相应表中写数据。并在调用sched.start()方法后,才会执行上述三条操作。
综上所述,我在sched.start()方法后再每次更新其qrtz_triggers表中该任务状态为WATING,就解决了该问题。
Quartz调度时好时坏解决方案
最新推荐文章于 2024-07-23 10:35:02 发布