羣集配置中石英的奇怪行爲

我正在開發定時服務。羣集配置中石英的奇怪行爲

該應用程序使用JDK 1.6，Spring Framework 2.5.6和Quartz 1.8.4開發來安排作業。

我有兩臺WebLogic Server 10.3.5的集羣服務器。

有時似乎石英的調度變得瘋狂。分析它發生的條件，羣集服務器之間似乎有一個大於一秒鐘的「失步」時鐘。但是，這種不同步並不總是由於服務器的系統時間，有時候即使機器的時鐘同步，JVM也會引入一些「延遲」。

有沒有人遇到同樣的問題？有沒有辦法解決它？

在此先感謝

來源

2013-03-29 Claudio Query

我使用Quartz 2.2.1每當集羣恢復時，我注意到一個奇怪的行爲。

例如，即使機器已經用ntpdate服務同步的I獲得簇實例恢復此消息：

org.quartz.impl.jdbcjobstore.JobStoreSupport findFailedInstances「該調度器實例（）仍處於活動狀態但被集羣中的另一個實例恢復。這可能會導致不一致的行爲「。

Here說，解決的辦法是：「同步所有羣集節點上的時間，然後重新啓動羣集的消息應該不會再出現在日誌中。」

由於每臺機器都是同步的，所以這個「延遲」是由JVM引入的？我不知道... :(

來源

2013-11-07 09:00:07 aloplop85

您是否找到解決此問題的方法？ –

對不起，我離開了這個項目，但我認爲關鍵是正確配置數據庫集羣，以便即使在其中一個節點關閉的情況下也能連續提供服務。 – aloplop85

當甲骨文使用JDBC-作業存儲與2.2.1版本中，我經歷了同樣的問題。

以我爲例，我是在單個節點上運行的石英然而，我注意到數據庫機器沒有時間與節點運行石英同步。

我激活NTPD數據庫機器運行石英機器上都，並在幾分鐘後，問題就走開了。

來源

2015-07-24 19:26:39 ercasta

這個問題幾乎總是歸因於時鐘偏移，即使你認爲你已經正確地設置了NTPd，仍然可以做一些事情發生：

我們認爲我們有NTPD工作（和它被正確配置了），但在AWS防火牆阻礙着NTP端口。 UDP 123.再次，這是UDP而不是TCP。
如果你不經常同步你會積累時鐘偏斜。許多主板上的定時器的準確性非常糟糕。因此，隨着時間的推移（突然間），你會得到這些Quartz錯誤。超過5分鐘，你會得到很多像Kerberos一樣的安全錯誤。

所以這個故事的道德是與NTPd同步，但經常做，並驗證它實際上工作。

來源

2016-08-30 17:56:33 sagneta

這個問題最常發生是因爲羣集節點中的時間不同步。但是，它也可能是由於應用程序與數據庫的連接不穩定造成的。此類連接問題可能由網絡問題（如果應用程序服務器和數據庫服務器位於不同計算機上）或性能問題（數據庫服務器進程由於某種原因緩慢處理請求）導致。

在這種情況下，可能會通過增加org.quartz.jobStore.clusterCheckinInterval值來減少此問題出現的機率。

來源

2016-10-20 09:56:12 Cloud

我面臨同樣的問題。首先，您應該檢查羣集的日誌和時間同步。

標記是消息在日誌：

08-02-2018 17:13:49.926 [QuartzScheduler_schedulerService-pc6061518092456074_ClusterManager] INFO o.s.s.quartz.LocalDataSourceJobStore - ClusterManager: detected 1 failed or restarted instances. 

08-02-2018 17:14:06.137 [QuartzScheduler_schedulerService-pc6061518092765988_ClusterManager] WARN o.s.s.quartz.LocalDataSourceJobStore - This scheduler instance (pc6061518092765988) is still active but was recovered by another instance in the cluster.

當第一節點觀察到，所述第二節點是不存在多於org.quartz.jobStore.clusterCheckinInterval它從集羣註銷第二個節點併除去它的所有觸發器。

看看的同步算法：org.quartz.impl.jdbcjobstore.JobStoreSupport.ClusterManager#run

可能發生時，「檢查中」需要很長時間。

我的解決方案是覆蓋org.quartz.impl.jdbcjobstore.JobStoreSupport#calcFailedIfAfter。硬編碼值'7500L'看起來像寬限期。我將其替換爲參數。

注意：如果使用SchedulerFactoryBean，註冊新的JobStoreSupport子類時要小心。春天強行註冊自己的商店org.springframework.scheduling.quartz.LocalDataSourceJobStore。

來源

2018-02-09 12:22:01

羣集配置中石英的奇怪行爲

回答

相關問題