quartz问题记录-missed their scheduled fire-time

Posted 悠悠乃

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了quartz问题记录-missed their scheduled fire-time相关的知识,希望对你有一定的参考价值。

这里有3个原因:
1.所有的woker thread(工作线程; 辅助线程)都在运行其他的job
2.scheduler(调度器)down了(关于这个down。我不太明确是shutdown了。。还是挂掉了。因此下文依旧用down。)
3.任务被安排在过去的某一时刻启动(此可能为代码错误)

我的

我的解决方法:修改quartz.properties文件中的org.quartz.threadPool.threadCount的值增大。(从原来的10增大到20),

      最近公司加了好多定时任务,导致线程不够用,至此quartz挂掉。

 

 

以下来源于网上:

可以简单地通过配置quartz.properties文件中的org.quartz.threadPool.threadCount,来增加worker thread的数量(默认为10)。但是当整个 application/server/scheduler (调度器)挂掉的时候,这方法仍然是无效的。这种Quartz无法启动指定触发器情况,叫做 misfire(http://fanyi.baidu.com/#en/zh/misfire 以下统一用misfire,汉语无法贴切表达)。
你知道当这种情况发生的时候,Quartz能做些什么吗? 其实,Quartz有许多的策略(叫misfire instructions,失火指示)可以处理问题,并且当你没有去想这方面问题的时候,它也有许多默认策略。但是为了使你的应用更加稳定和可预测(尤其是在高负载和可维护性上),你应该有意识的去确保triggers 和 jobs工作正常。

基于你用的trigger,会有不同的配置选项(对misfire instructions有效)。当然,不同的trigger也会使Quartz有不同的行为(叫做smart policy,明智的决策)。尽管文档中有misfire instructions的描述,但是我发现都很难理解它所想表达的意思,因此,我写下这篇简短的总结。

 

在我深入细节之前,还有一个配置需要说明下:org.quartz.jobStore.misfireThreshold(毫秒级),默认是60000(一分钟)。它定义了trigger被认为是misfired了的时限。

 

基于默认配置,如果trigger应该在30秒以前被触发,那么很愉快地,Quartz就把它搞定了。这种延迟(delay)不能叫失火。

 

然而当trigger被发现,延迟了61秒时,那么专门的“失火处理者(misfire handler thread)”就会按照misfire instructions去处理它了。

 

 

 

为了测试效果,我们将这个时间设置为1000(即1秒),这样就能很快的测试“失火”了。


 

第一个例子,是一个不需要重复触发的普通trigger,我们来看看普通trigger调度器是怎么处理“失火”,并让它运行一次的:

 

【原文:Simple trigger without repeating In our first example we will see how misfiring is handled by simple triggers scheduled to run only once:】

 

1.val trigger = newTrigger().
2.startAt(DateUtils.addSeconds(new Date(), -10)).
3.build()

 

同样的trigger,但是明确设置了misfire instruction handler(失火处理者):

 

1.val trigger = newTrigger().
2.startAt(DateUtils.addSeconds(new Date(), -10)).
3.withSchedule(
4.simpleSchedule().
5.withMisfireHandlingInstructionFireNow() //MISFIRE_INSTRUCTION_FIRE_NOW
6.).
7.build()

 

为了测试,我将trigger设置为10秒前被调度(即当创建后,就已经晚于启动时间10秒)。在实际使用时,我们基本上永远不会这么设置。

 

换句话说,如果我们正确的设置了trigger,但是当需要被调度的时候,调度器down了或者没有空闲的worker thread了。那么,Quartz怎么处理这种extraordinary(罕见,古怪)的情况呢?

 

在第一段代码中,没有设置misfire instruction(so called smart policy is used in that case 这句不太会翻译。。。。)。

 

第二段代码中,明确指定了当misfire发生时,我们希望采取的行为。

 

来看下表:

 

 

 

指令 Instruction 意义 Meaning
smart policy - default See: withMisfireHandlingInstructionFireNow
withMisfireHandlingInstructionFireNow
MISFIRE_INSTRUCTION_FIRE_NOW
调度器发现misfire情况后,立即执行job。
这是smart policy。
例如:
你让一些系统清理功能在2点执行。但是很不幸,应用在那段时间由于维护,关闭了,直到3点才恢复。这样trigger就misfire了,然后调度器会尝试修复这种情况,在3点启动后,尽快执行。
withMisfireHandlingInstructionIgnoreMisfires
MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY
See: withMisfireHandlingInstructionFireNow
withMisfireHandlingInstructionNextWithExistingCount
MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_EXISTING_COUNT
See: withMisfireHandlingInstructionNextWithRemainingCount
withMisfireHandlingInstructionNextWithRemainingCount
MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT
什么都不做。misfire被忽略了,并且没有后续的执行。当你想要彻底放弃被misfire的执行时,可以使用这个指令。
例如:
trigger是要启动录制一个电视节目。但是被misfire了,2个小时候,才发现。  
【PS: 这个不是太理解,只是按照原文翻译过来,如果要用,请自行测试。。。】
withMisfireHandlingInstructionNowWithExistingCount
MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT
See: withMisfireHandlingInstructionFireNow
withMisfireHandlingInstructionNowWithRemainingCount
MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_REMAINING_REPEAT_COUNT
See: withMisfireHandlingInstructionFireNow

 

 

 

 

 

普通trigger重复执行指定次数。这种情形更加复杂。想象一下,我们有一些需要重复执行指定次数的job:

 

 

 

01.val trigger = newTrigger().
02.startAt(dateOf(900)).
03.withSchedule(
04.simpleSchedule().
05.withRepeatCount(7).
06.withIntervalInHours(1).
07.WithMisfireHandlingInstructionFireNow()  //or other
08.).
09.build()

 

在这个例子中,trigger从今天9点开始(startAt(dateOf(9, 0, 0)),共触发8次(第一次执行,和7次重复)。

 

按理,最后一次执行应该在下午4点被触发。假设由于某些原因,在9点和10点调度器没有执行job,并且直到10:15才被系统发现misfire,也就是misfire了2次。这种情况下,调度器会怎么样呢?

 

 

 

指令 Instruction 意义 Meaning
smart policy - default See:withMisfireHandlingInstructionNowWithExistingCount
withMisfireHandlingInstructionFireNow
MISFIRE_INSTRUCTION_FIRE_NOW
See:withMisfireHandlingInstructionNowWithRemainingCount
withMisfireHandlingInstructionIgnoreMisfires
MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY
尽快启动所有被启动的trigger,并将调度置为正常。
例如:
在我们上面的例子中,调度器会立即执行9点和10点的任务,并等待11点时,继续按正常的调度执行。
备注:当处理misfire时,我们同样要注意到,实际job执行的时间,已经滞后于应该执行的时间。这意味着,你不能简单地的依赖当前系统时间,而是应该使用 JobExecutionContext .getScheduledFireTime()去获取。
1.def execute(context: JobExecutionContext) {
2.val date = context.getScheduledFireTime
3.//...
4.}
withMisfireHandlingInstructionNextWithExistingCount
MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_EXISTING_COUNT
调度器不会马上有反应。它会等待下一次执行,然后根据应该调度次数去运行trigger。
See also: withMisfireHandlingInstructionNextWithRemainingCount
例如:
在10点15发现2次misfire。调度器会等到11点,继续执行,并会每小时执行1次,共执行8次调度操作,直到下午6点停止(本该4点停止的。)
withMisfireHandlingInstructionNextWithRemainingCount
MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT
调度器会抛弃被misfire的操作,然后等待下次执行。这样,执行的总次数,就会小于配置的次数。
例如:在10点15,2次misfire的执行都被丢弃了。调度器会等到下个执行时间-11点,然后继续触发其余的trigger,直到4点。事实上,这种情况就像misfire从未发生过一样。
withMisfireHandlingInstructionNowWithExistingCount
MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT
第一次misfire的trigger会立即执行,而后会按设置的间隔,依次执行剩余的trigger。实际上,就像misfire的trigger的第一次触发时间,被平移到了当前时间。
例如:
调度器会在10点15第一次运行misfire的trigger,然后隔1个小时,在11点15执行第二次。共执行8次,最后一次,在下午5点15。

withMisfireHandlingInstructionNowWithRemainingCount
MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_REMAINING_REPEAT_COUNT

第一次misfire的操作,被立即执行。其余被misfire的操作,会被抛弃。
剩余没有被misfire的trigger,会按固定间隔被触发。
例如:
调度器会在10点15运行第一次被misfire的操作(9点的。)。然后,它抛弃其余被misfire的(10点那一次)。最后,它会等1小时继续触发6个trigger:
11:15,12:15.... 4:15 PM。


 

 

这是一个基于指定间隔、并重复无数次的trigger:

 

 

 

01.val trigger = newTrigger().
02.startAt(dateOf(900)).
03.withSchedule(
04.simpleSchedule().
05.withRepeatCount(SimpleTrigger.REPEAT_INDEFINITELY).
06.withIntervalInHours(1).
07.WithMisfireHandlingInstructionFireNow()  //or other
08.).
09.build()

 

trigger应该从今天9点开始(startAt(dateOf(9, 0, 0)),每隔小时触发一次。然而调度器在9点到10点都没有执行job(比如关闭了系统、线程不够等等。。前面有介绍),并且在10点15时才被发现,misfire了2次。这种情况比那种执行执行次数的trigger更加普遍。

 

 

 

指令 Instruction 意义 Meaning
smart policy - default See:withMisfireHandlingInstructionNowWithExistingCount
withMisfireHandlingInstructionFireNow
MISFIRE_INSTRUCTION_FIRE_NOW
See: withMisfireHandlingInstructionNowWithRemainingCount
withMisfireHandlingInstructionIgnoreMisfires
MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY
https://jira.terracotta.org/jira/browse/QTZ-283
调度器会立即执行所有misfire的trigger,然后继续正常调度。
例如:
9点和10点的trigger会立即执行,下次执行将按计划执行(下一次是11点执行)。

withMisfireHandlingInstructionNextWithExistingCount
MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_EXISTING_COUNT
See:withMisfireHandlingInstructionNextWithRemainingCount
withMisfireHandlingInstructionNextWithRemainingCount
MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT
不做任何事情,misfire的情况被忽略掉。然后,调度器按设置的间隔等待下次执行。
例如:
9点和10点misfire的执行被忽略掉。第一次执行会在11点会开始。
Example scenario: Misfired execution at 9 and 10 AM are discarded. The first execution occurs at 11 AM.

withMisfireHandlingInstructionNowWithExistingCount
MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT
See:withMisfireHandlingInstructionNowWithRemainingCount
withMisfireHandlingInstructionNowWithRemainingCount
MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_REMAINING_REPEAT_COUNT


第一次misfire的执行会被立即运行,其余的被忽略。下次执行会在设置的间隔时间后被触发。实际上,就是第一次执行被推迟到了当前时间。
例如:
调度器在10点15立即执行misfire的trigger,然后等待一个小时后,在11点15时,执行第二次。以后会每隔一小时。


定时触发    CRON trigger

 

定时触发是Quartz中最常见的。它有另外两个有效的trigger:DailyTimeIntervalTrigger(比如每25分钟一次)和CalendarIntervalTrigger(比如5个月执行一次)。They support triggering policies not possible in both CRON and simple triggers.(不会译- -!),但是他们和CRON trigger一样,支持同样的misfire handling instructions(失火处理指令)。

 

 

 

1.val trigger = newTrigger().
2.withSchedule(
3.cronSchedule("0 0 9-17 ? * MON-FRI").
4.withMisfireHandlingInstructionFireAndProceed()  //or other
5.).
6.build()

 

这个例子是,trigger在每周一到周五的早上9点到下午5点间,每小时被触发一次。但是两次触发被misfire了,并且在10点15时,才发现这个情况。请注意,他们的失火指令效果与普通trigger是不同的:

 

 

 

指令 Instruction 意义 Meaning
smart policy - default See: withMisfireHandlingInstructionFireAndProceed
withMisfireHandlingInstructionIgnoreMisfires
MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY
https://jira.terracotta.org/jira/browse/QTZ-283
所有被misfire的执行会被立即执行,然后按照正常调度继续执行trigger。
例如:
9点和10点的执行(misfire的2个)被立即执行,下次执行将在11点被准时执行。
withMisfireHandlingInstructionFireAndProceed
MISFIRE_INSTRUCTION_FIRE_ONCE_NOW
立即执行第一次misfire的操作,并且放弃其他misfire的(类似所有misfire的操作被合并执行了)。然后继续按调度执行。无论misfire多少次trigger的执行,都只会立刻执行1次。
例如:
9点和10点的被合并执行一次(换句话说,10点需要执行的那次,被pass了)。下次执行将在11点被准时执行。
withMisfireHandlingInstructionDoNothing
MISFIRE_INSTRUCTION_DO_NOTHING
所有被misfire的执行都被忽略掉,调度器会像平时一样等待下次调度。
例如:
9点和10点的被忽略掉,好像什么都没发生一样。下次执行将在11点被执行。
   

 

QTZ-283NoteQTZ-283: MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY not working with JDBCJobStore - apparently there is a bug when JDBCJobStore is used, keep an eye on that issue. (在用JDBCJobStore 时,MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY 没有生效。显然,这是在使用JDBCJobStore时的一个bug,关注下。)

 

 

 

如你所有,根据实际的设定,不同的trigger会有不同的行为。此外,虽然它提供了smart policy(明智的决策),但是真正使用时,还是要取决于业务需求。

 

从本质上看,主要有三种策略:忽略,立即运行然后继续正常执行,忽略misfire的并等待下次执行。( 原文: ignorerun immediately and continue and discard and wait for next. )

 

它们有不同的应用场景:

 

当你需要确保每次调度任务都要被执行的时候,即时它意味着多个misfire的trigger会被触发,那么用ignore policies。试想一下,有一个任务,需要每小时,都根据上一小时的订单去生成报表。如果服务被关闭了8个小时,那你可能仍然是尽快得到那些报表的。这种情况下,配置ignore policies,调度器会尽快将那8小时的调度任务运行一遍的。尽管晚了几个小时,但是仍然是被执行了(最终报告到手了。^_^)。

 

当你需要任务被定期执行,并且当出现misfire的情况后立即运行一次的时候,那么使用now* policies。试想一下,一个任务是每分钟清空文件夹 /tmp。如果调度器在20分钟内繁忙,最后终于可以执行这个任务了,那么你肯定不会希望它执行20次的!一次就足够了,但是要尽快执行。而后,再回到正常的执行间隔--1分钟。

 

当你希望任务能在特定时间点运行的时候,使用next* policies不错。比如你需要在每个整点后15分钟抓取股票的价格。它们的变化非常快,然后现在已经整点后20分了,那么不必烦恼。你刚好错过了5分钟,但是现在你已经不在乎(那时候的价格)了。这时,一个时间间隙总好过一个不准确的值。这种情况Quartz只要跳过misfire的操作,等待下次执行就好了。

 

以上是关于quartz问题记录-missed their scheduled fire-time的主要内容,如果未能解决你的问题,请参考以下文章

sql http://mono.software/2017/07/13/missing-incorrectly-set-up-and-unused-indexes-and-their-impact-o

everything of people’s life can changed in their twenties

mysql:如何删除字段开头或结尾的字符

Quartz重复执行问题记录

Quartz学习记录

分布式定时任务调度框架 - Quartz学习及实战记录笔记