Wie die Erkennung von Knoten durch Knoten fehlschlägt

Question

Meine Produktionsumgebung, in der ein Java-Scheduler-Job mit Quarz 2.1.4 ausgeführt wird. auf Weblogic-Cluster-Server mit 4 Maschinen und nur einem Zeitplan Job auf einem Cluster-Knoten (Knoten 1) normalerweise für ein paar Monate ausführen, aber Knoten 2 plötzlich finden den Knoten 1 scheitern bei der Übernahme der ausführenden Job letzte Nacht. In der Tat, der Knoten 1 ohne Fehler (entsprechend dem Server, Netzwerk, Datenbank, Anwendungsprotokoll), verursachte dieses Ereignis doppelte Nachricht erstellt aufgrund von 2 Prozess gleichzeitige Ausführung.

Was ist der Mechanismus von Quarz zur Erkennung von Knotenfehlern? Durch Ping-Scan oder Herzschlag Ping über UCP Broadcast oder Datenbank Reaktionszeit andere? Irgendeine Konfiguration drauf?

Ich habe die Quarz-Konfigurationsanleitung http://quartz-scheduler.org/documentation/quartz-2.1.x/configuration/ConfigJDBCJobStoreClustering gelesen, aber es gibt keine Antwort.

Ich benutze JDBCJobstore. Nach der Überprüfung der Details haben wir festgestellt, dass eine Datenbankanweisung (Oracle) abnormal lang (von 5 Sekunden bis 30 Sekunden) ausgeführt wird. Der Vorfall ereignete sich in dieser Zeit. Glaubst du, dass es zusammenhängt?

meine Konfiguration ist

` org.quartz.threadPool.threadCount = 10

org.quartz.threadPool.threadPriority = 5

org.quartz.jobStore.misfireThreshold = 10000

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

Hat jemand diese Information? Vielen Dank.

Answer 1

Ich weiß, die Antwort ist sehr spät, aber vielleicht jemand wie wir beide wird es immer noch brauchen.

Kurze Version: Es wird alles von der DB behandelt. Eine wichtige Eigenschaft wäre org.quartz.jobStore.clusterCheckinInterval.

Lange Version (alle Kredite gehen zu http://flylib.com/books/en/2.65.1.91/1/):

Detecting Fehlgeschlagen Scheduler Knoten

Wenn eine Scheduler-Instanz der Check-in-Routine führt, sieht es nach sehen, ob es andere Scheduler-Instanzen, die nicht eingecheckt haben, als sie sollten. Dazu prüft es die Tabelle SCHEDULER_STATE und sucht nach Schedulern, die einen Wert in der Spalte LAST_CHECK_TIME haben, der älter ist als die Eigenschaft org.quartz.jobStore.clusterCheckinInterval (wird im nächsten Abschnitt behandelt). Wenn ein oder mehrere Knoten nicht eingecheckt haben, geht der laufende Scheduler davon aus, dass die anderen Instanzen fehlgeschlagen sind.

Zusätzlich wird der nächste Absatz könnte auch wichtig sein:

Lauf Knoten auf getrennten Maschinen mit Unsynchronisierte Clocks

Wie Sie jetzt feststellen können, wenn Sie Knoten auf verschiedenen Maschinen laufen und Die Uhren sind nicht synchronisiert, Sie können unerwartete Ergebnisse erhalten. Dies ist , weil ein Zeitstempel verwendet wird, um andere Instanzen der beim letzten Einchecken eines Knotens zu informieren. Wenn die Uhr dieses Knotens für die Zukunft festgelegt wurde, könnte ein laufender Scheduler nie erkennen, dass ein Knoten ausgefallen ist. Wenn andererseits eine Uhr an einem Knoten in der Vergangenheit gesetzt ist, könnte ein -Knoten annehmen, dass der Knoten ausgefallen ist und versuchen, zu übernehmen und seine Jobs erneut auszuführen. In jedem Fall ist es nicht das Verhalten, das Sie wollen. Wenn Sie verschiedene Maschinen in einem Cluster verwenden (normalerweise ), müssen Sie die Uhren synchronisieren. Weitere Informationen dazu finden Sie im Abschnitt "Quartz Clustering Cookbook" weiter unten in diesem Kapitel.