Fallimento dei nodi di rilevamento del quarzo

Question

L'ambiente di produzione che esegue un processo di pianificazione java utilizzando il quarzo 2.1.4. su un server cluster weblogic con 4 macchine e un solo lavoro di pianificazione eseguito su un nodo cluster (nodo 1) normalmente per alcuni mesi, ma il nodo 2 rileva improvvisamente che il nodo 1 non riesce a rilevare il lavoro in esecuzione la scorsa notte. Infatti, il nodo 1 senza errore (in base al server, alla rete, al database, al registro dell'applicazione), questo evento ha causato la creazione di un messaggio duplicato a causa dell'elaborazione simultanea di due processi.

Qual è il meccanismo del quarzo per rilevare il guasto del nodo? Tramite ping scan o heart beat ping via broadcast UCP o tempo di risposta del database altro? Qualche configurazione su di esso?

Ho letto la guida alla configurazione del quarzo http://quartz-scheduler.org/documentation/quartz-2.1.x/configuration/ConfigJDBCJobStoreClustering , ma non c'è risposta.

Sto usando JDBCJobstore. Dopo aver controllato i dettagli, abbiamo scoperto che esiste un'istruzione di database (Oracle) in esecuzione anormale lunga (da 5 secondi a 30 secondi). L'incidente è accaduto in questo periodo di tempo. Pensi che sia collegato?

mia configurazione è

` org.quartz.threadPool.threadCount = 10

org.quartz.threadPool.threadPriority = 5

org.quartz.jobStore.misfireThreshold = 10000

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

Qualcuno ha questa informazione? Grazie.

Answer 1

So che la risposta è molto tardi, ma forse qualcuno come noi ne avrà ancora bisogno.

Versione corta: è tutto gestito da DB. Proprietà importante sarebbe org.quartz.jobStore.clusterCheckinInterval.

Versione lunga (tutti i crediti vanno a http://flylib.com/books/en/2.65.1.91/1/):

Rilevazione riuscita Scheduler nodi

Quando un'istanza Scheduler effettua il check-in di routine, sembra di vedere se ci sono altre Istanze dello scheduler che non hanno effettuato il check-in quando si supponeva che fossero . Lo fa controllando la tabella SCHEDULER_STATE e alla ricerca di scheduler che hanno un valore nella colonna LAST_CHECK_TIME che è più vecchio di proprietà org.quartz.jobStore.clusterCheckinInterval (discussa nella prossima sezione ). Se uno o più nodi non hanno effettuato il check-in, l'Utilità di pianificazione in esecuzione presuppone che le altre istanze abbiano avuto esito negativo.

Inoltre paragrafo successivo potrebbe anche essere importante:

corso nodi su macchine separate con non sincronizzati Clocks

Come si può constatare, ormai, se si esegue nodi su diverse macchine e gli orologi non sono sincronizzati, è possibile ottenere risultati imprevisti. Questo è perché viene utilizzato un timestamp per informare altre istanze di l'ultima volta in cui è stato archiviato un nodo. Se l'orologio di quel nodo era impostato per il futuro, uno Scheduler in esecuzione potrebbe mai rendersi conto che un nodo è andato in basso. D'altra parte, se un orologio su un nodo si trova nel passato, un nodo potrebbe supporre che il nodo è andato giù e tentare di prendere in consegna ed eseguire di nuovo i suoi posti di lavoro. In entrambi i casi, non è il comportamento desiderato da . Quando si utilizzano macchine diverse in un cluster (che è il caso normale ), assicurarsi di sincronizzare gli orologi. Vedere la sezione "Libro di ricette per il clustering del quarzo", più avanti in questo capitolo per i dettagli su come fare ciò.