Question

我正在开发预定服务。

该应用程序是使用JDK 1.6，Spring Framework 2.5.6和Quartz 1.8.4开发的，用于安排作业。

我有两台带有WebLogic Server 10.3.5的群集服务器。

有时似乎石英的调度变得疯狂。分析它发生的条件，似乎在集群服务器之间存在大于一秒的时钟“去同步”。然而，这种去同步并不总是由于服务器的系统时间，有时似乎即使机器的时钟同步，JVM也会引入一些“延迟”。

有没有人遇到同样的问题？有办法解决吗？

提前致谢

Answer 1

在Oracle 2.2.1版上使用JDBC-JobStore时，我遇到了同样的问题。

就我而言，我在一个节点上运行Quartz。但是，我注意到数据库机器与运行Quartz的节点没有时间同步。

我在数据库机器和运行Quartz的机器上激活了ntpd，几分钟后问题就消失了。

Answer 2

我正在使用Quartz 2.2.1，每当发生集群恢复时我都会注意到一种奇怪的行为。

例如，即使计算机已与ntpdate服务同步，我也会在集群实例恢复时获取此消息：

org.quartz.impl.jdbcjobstore.JobStoreSupport findFailedInstances“此调度程序实例（）仍处于活动状态，但已由群集中的另一个实例恢复。这可能会导致行为不一致“。

Here表示解决方案是：“ 在所有群集节点上同步时间，然后重新启动群集。消息不应再出现在日志中。” < /强>

当每台机器同步时，JVM可能会引入这种“延迟”吗？我不知道...... :(

Answer 3

这个问题几乎总是归因于时钟偏差。即使你认为你有正确的NTPd设置，仍然可能发生一些事情：

我们认为我们有NTPd工作（并且配置正确）但在AWS上防火墙阻止了NTP端口。 UDP 123.再次，那是UDP而不是TCP。
如果您不经常同步，则会累积时钟偏差。许多主板上的定时器的准确性是众所周知的。因此，随着时间（天）突然你会得到这些Quartz错误。超过5分钟，您会收到许多安全错误，例如Kerberos。

因此，这个故事的寓意是与NTPd同步，但经常做，并验证它实际上是有效的。

Answer 4

由于群集节点中的时间不同步，最常发生此问题。但是，它也可能是由于应用程序与DB的连接不稳定造成的。此类连接问题可能是由网络问题（如果应用程序服务器和数据库服务器位于不同的计算机上）或性能问题（数据库服务器进程由于某种原因请求非常缓慢）引起的。

在这种情况下，可以通过增加org.quartz.jobStore.clusterCheckinInterval值来减少出现此问题的可能性。

Answer 5

我遇到了同样的问题。首先，您应该检查群集的日志和时间同步。

标记是日志中的消息：

org.quartz.jobStore.clusterCheckinInterval

当第一个节点观察到第二个节点不存在超过org.quartz.impl.jdbcjobstore.JobStoreSupport.ClusterManager#run时，它从群集中注销第二个节点并删除其所有触发器。

查看同步算法：org.quartz.impl.jdbcjobstore.JobStoreSupport#calcFailedIfAfter

当'登记'需要很长时间时，可能会发生这种情况。

我的解决方案是覆盖org.springframework.scheduling.quartz.LocalDataSourceJobStore。硬编码值'7500L'看起来像宽限期。我将其替换为参数。

注意：如果使用SchedulerFactoryBean，请注意注册新的JobStoreSupport子类。 Spring强行注册自己的商店ALTER DATABASE prueba CHARACTER SET utf8 COLLATE utf8_spanish_ci;。