【问题标题】:Quartz simple trigger not working after sometime石英简单触发器在一段时间后不起作用
【发布时间】:2017-08-23 01:52:59
【问题描述】:

我正在使用石英简单触发器(石英 2.2.1),设置为无限重复。所有计划在生产中运行良好,但最近他们停止工作,并且下一次开火时间也没有更新。 如果我使用 rescheduleJob 石英 API 更新计划,它会在一段时间内正常工作,然后再次进入卡住状态。 关于这是如何发生的任何信息?

线程转储显示所有处于定时等待状态的线程,并带有 onObject 监控。

"UDPQuartzScheduler_Worker-8" #49 prio=4 os_prio=0 tid=0x00007f88d71a8000 nid=0x30b6 in Object.wait() [0x00007f8928b30000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:568)
    - locked <0x00000006ddc9d6b0> (a java.lang.Object)

"UDPQuartzScheduler_Worker-7" #48 prio=4 os_prio=0 tid=0x00007f88d71a6000 nid=0x30b5 in Object.wait() [0x00007f8928c31000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:568)
    - locked <0x00000006ddc9d6f8> (a java.lang.Object)

"UDPQuartzScheduler_Worker-6" #47 prio=4 os_prio=0 tid=0x00007f88d71a4000 nid=0x30b4 in Object.wait() [0x00007f8928d32000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:568)
    - locked <0x00000006ddc9f000> (a java.lang.Object)

【问题讨论】:

  • 您需要深入挖掘。最后一次执行是否正确完成?执行时间是否比重复间隔更长?我会专注于最后一次执行,看看它是否有任何答案,调试和日志记录应该会给你更多关于为什么跳过执行的数据。
  • @PredragMaric 嘿,所以发生的事情是应用程序数据库(mysql)关闭了一段时间,因此石英无法连接到数据库。困扰我的是,即使数据库启动并且我重新启动了应用程序,为什么石英根本没有接受预定的作业。
  • 与我们在一个项目中遇到的问题完全相同(仅在 Oracle 上)。从来没有找到问题的根源,但我们的结论是 Quartz 只需要在 DB 重新启动时也重新启动。我们有很多奇怪的症状,除了简单地跳过执行(同一个作业的多次执行等)
  • @PredragMaric 你可能想把这个结论变成一个答案。
  • @PredragMaric 我测试了这个假设,停止了 mysql 服务并在 10 分钟后再次启动它(同时检查整个时间的应用程序日志)。收到如下错误:org.quartz.JobPersistenceException:无法从数据源'springNonTxDataSource.schedulerFactoryBean'获取数据库连接:com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:通信链接失败但是当我启动mysql时,quartz能够无需重新启动应用程序即可启动下一个触发器。

标签: java quartz-scheduler


【解决方案1】:

即使增加线程数,您也可能会遇到同样的问题,因为您的工作线程会再次卡住。 要解决此问题,您必须检查您的工作线程代码并检查他们卡住的天气某些任务执行时间过长(基本上它发生在您编写时/读取太多数据)。这两个原因也造成了失火问题。

如果您找不到与我上面提到的点相关的任何内容,那么您可以通过工作线程创建单独的线程,而不是在工作线程上执行它。它肯定会解决你的问题,但是如果你有太多线程卡在应用程序进程中,那么你的应用程序就会卡住,但同时你会从应用程序进程堆栈跟踪中得到这个问题的确切原因。

【讨论】:

    【解决方案2】:

    与我们在一个项目中遇到的问题完全相同(仅在 Oracle 上)。从来没有深究过问题的根源,但我们的结论是,重启 DB 时也需要重启 Quartz。

    除了简单地跳过执行之外,我们还有很多奇怪的症状——同一作业的多次执行、集群设置中未同步的工作人员等等。所有这些都是随机的,我们无法识别任何模式。

    【讨论】:

    • 在检查多个应用程序时,不需要启动服务器,当 DB 启动时,quartz 会自动选择下一次运行。就我而言,我只使用了 8 个线程,现在我将其增加到 20 个。目前还没有遇到该应用程序中的问题。关于如何在石英上启用日志记录的任何想法。
    • @Karshit Logging 应该记录在案,不记得细节了。我们有一个集群石英装置,也许这​​就是导致问题的原因
    猜你喜欢
    • 2013-01-29
    • 1970-01-01
    • 2011-09-02
    • 2020-12-15
    • 1970-01-01
    • 1970-01-01
    • 2013-05-17
    • 1970-01-01
    • 2021-08-10
    相关资源
    最近更新 更多