石英检测节点如何失败答案

【问题标题】：How quartz detect nodes fails石英检测节点如何失败
【发布时间】：2012-10-19 02:43:11
【问题描述】：

我的生产环境使用石英 2.1.4 运行 java 调度程序作业。在具有 4 台机器的 weblogic 集群服务器上，只有一个计划作业在一个集群节点（节点 1）上正常执行几个月，但节点 2 突然发现节点 1 在昨晚接管执行作业时失败。事实上，节点1没有错误（根据服务器，网络，数据库，应用程序日志），这个事件导致由于2进程并发执行而创建了重复消息。

quartz检测节点故障的机制是什么？通过 ping 扫描，或通过 UCP 广播的心跳 ping，或数据库响应时间等？有什么配置吗？

我已阅读石英配置指南 http://quartz-scheduler.org/documentation/quartz-2.1.x/configuration/ConfigJDBCJobStoreClustering ，但没有答案。

我正在使用 JDBCJobstore。经过详细检查，我们发现有一个数据库（Oracle）语句执行异常长（从5秒到30秒）。事件发生在这段时间。你觉得有关系吗？

我的配置是

` org.quartz.threadPool.threadCount=10

org.quartz.threadPool.threadPriority=5

org.quartz.jobStore.misfireThreshold = 10000

org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX `

谁有这方面的信息？谢谢。

【问题讨论】：

标签： cluster-computing quartz-scheduler

【解决方案1】：

我知道答案很晚，但也许像我们俩这样的人仍然需要它。

短版：全部由 DB 处理。重要的属性是 org.quartz.jobStore.clusterCheckinInterval。

长版（所有学分归http://flylib.com/books/en/2.65.1.91/1/）：

检测失败的调度程序节点

当调度程序实例执行签入例程时，它看起来查看是否有其他调度程序实例没有签入他们应该这样做。它通过检查 SCHEDULER_STATE 来做到这一点表并寻找在早于属性的 LAST_CHECK_TIME 列 org.quartz.jobStore.clusterCheckinInterval（在下一个讨论部分）。如果一个或多个节点尚未签入，则运行调度程序假定其他实例已失败。

另外，下一段可能也很重要：

在时钟不同步的不同机器上运行节点

您现在可以确定，如果您在不同的机器上运行节点并且时钟不同步，你会得到意想不到的结果。这是因为时间戳被用于通知其他实例上次有一个节点签入。如果该节点的时钟设置为未来，一个正在运行的调度器可能永远不会意识到一个节点已经消失向下。另一方面，如果一个节点上的时钟是在过去设置的，则节点可能会假设该节点已关闭并尝试接管并重新运行其作业。无论哪种情况，这都不是您的行为想。当您在集群中使用不同的机器时（即正常情况下），请务必同步时钟。见章节本章后面的“Quartz Clustering Cookbook”详细了解如何这样做。

【讨论】：