Garantire l'elaborazione seriale dei messaggi JMS in un cluster OC4J

Question

Abbiamo un'applicazione che elabora i messaggi JMS utilizzando un bean basato sui messaggi. Questa applicazione è distribuita su un server delle applicazioni OC4J. (10.1.3)

Stiamo pianificando di distribuire questa applicazione su più server di applicazioni OC4J che verranno configurati per l'esecuzione in un cluster.

Il problema è con l'elaborazione dei messaggi JMS in questo cluster. Dobbiamo garantire che sia elaborato un solo messaggio nell'intero cluster OC4J alla volta. Ciò è necessario, poiché i messaggi devono essere elaborati in ordine cronologico.

Conosci un parametro di configurazione che controlla l'elaborazione dei messaggi in un cluster OC4J?

O pensi che dobbiamo implementare il nostro codice di sincronizzazione che sincronizzerà i bean basati sui messaggi attraverso il cluster?

Answer 1

Ho eseguito l'elaborazione sequenziale dei messaggi in un cluster su una scala piuttosto ampia - 1,5 milioni + messaggio / giorno, usando una combinazione del modello dei consumatori concorrenti e un modello di leasing.

Ecco il kicker, però: la tua esigenza di poter elaborare solo una trans alla volta ti impedirà di raggiungere i tuoi obiettivi. Avevamo gli stessi requisiti di base: i messaggi dovevano essere elaborati in ordine. Almeno, pensavamo di averlo fatto. Poi abbiamo avuto un'epifania - dato che abbiamo riflettuto maggiormente sul problema, ci siamo resi conto che non avevamo bisogno di un ordinamento totale. In realtà abbiamo richiesto l'ordine solo all'interno di ciascun account. Pertanto, è possibile distribuire il carico tra i server in un cluster assegnando intervalli di account a server diversi nel cluster. Quindi, ciascun server era responsabile dell'elaborazione dei messaggi per un determinato account in ordine.

Ecco la seconda parte intelligente: abbiamo usato un modello di lease per assegnare dinamicamente intervalli di account a vari server nel cluster. Se un server nel cluster si arrestasse, un altro prenderebbe il contratto di locazione e assumerebbe la responsabilità del primo server.

Questo ha funzionato per noi e il processo è rimasto in produzione per circa 4 anni prima di essere sostituito a causa di una fusione tra società.

Modifica:

Spiego questa soluzione in modo più dettagliato qui: http://coders-log.blogspot.com/2008/12/favorite-projects-series-installment-2.html

Modifica:

Okay, capito. Stai già eseguendo l'elaborazione al livello di cui hai bisogno, ma poiché sei distribuito in un cluster, devi assicurarti che solo un'istanza del tuo MDB stia attivamente attingendo i messaggi dalla coda. Inoltre, hai bisogno della soluzione praticabile più semplice.

Non è necessario abbandonare il meccanismo MDB che hai adesso, non credo. Fondamentalmente, ciò di cui stiamo parlando qui è un requisito per un meccanismo di blocco distribuito, non per esprimere una frase troppo elaborata.

Quindi, lasciatemi suggerire questo. Nel punto in cui il tuo MDB si registra per ricevere messaggi dalla coda, dovrebbe controllare il blocco distribuito e vedere se riesce a catturarlo. Il primo MDB ad afferrare il lucchetto vince e solo lui si registrerà per ricevere messaggi. Quindi, ora hai la tua serializzazione. Quale forma dovrebbe assumere questa serratura? Ci sono molte possibilità Bene, che ne dici di questo. Se hai accesso a un database, il suo blocco transazionale fornisce già alcune delle cose di cui hai bisogno. Crea una tabella con una singola riga. Nella riga è l'identificatore del server che attualmente detiene il blocco e un tempo di scadenza. Questo è il contratto di locazione del server. Ogni server deve avere un modo per generare il suo identificativo univoco, ad esempio il nome del server più un ID thread.

Se un server può ottenere l'accesso di aggiornamento alla riga e il lease è scaduto, dovrebbe afferrarlo. Altrimenti, si arrende. Se acquisisce il contratto di locazione, deve aggiornare la riga con un orario nel prossimo futuro, ad esempio circa cinque minuti, e impegnare l'aggiornamento. Il server attivo dovrebbe aggiornare il contratto di locazione prima della scadenza. Consiglio di aggiornarlo quando rimane metà del tempo rimanente, quindi ogni 2-1 / 2 minuti se il contratto di locazione scade tra cinque. Con questo, ora hai il failover. Se l'MDB attivo muore, subentra un altro MDB (e solo uno).

Dovrebbe essere piuttosto semplice, credo. Ora, vuoi che gli MDB inattivi controllino il blocco di tanto in tanto per vedere se è stato liberato.

Quindi, l'MDB attivo e gli MDB inattivi devono fare qualcosa periodicamente. Potresti farli generare un thread separato per farlo. Molti produttori di motori delle applicazioni non saranno contenti se lo fai, ma l'aggiunta di un thread non è un grosso problema, soprattutto perché trascorre la maggior parte del tempo a dormire. Un'altra opzione sarebbe quella di legare il meccanismo del timer fornito da molti motori e farlo svegliare periodicamente dall'MDB per controllare il contratto di locazione.

Oh, e comunque - assicurati che gli amministratori del server utilizzino NTP per mantenere ragionevolmente sincronizzati gli orologi.

Answer 2

Primo punto: questo è un design piuttosto scadente e limiterai seriamente le prestazioni, potendo solo elaborare un singolo messaggio alla volta. Suppongo che stai raggruppando solo per tolleranza d'errore, perché non otterrai miglioramenti delle prestazioni?

Stai utilizzando l'implementazione JMS predefinita con OC4J o un'altra?

Ho usato IBM MQ in passato e che aveva una caratteristica che una coda poteva essere contrassegnata come esclusiva, il che significava che solo un client poteva connettersi ad essa. Ciò sembrerebbe offrire ciò che desideri.

Un'alternativa sarebbe quella di introdurre un ID sequenza (semplice come un contatore incrementale) e il client che elabora il messaggio verificherebbe che l'ID sequenza sia il valore atteso successivo, altrimenti il ??messaggio rimandato. Questo approccio richiede che i diversi client mantengano l'ultimo ID sequenza valido che hanno visto in alcuni archivi di dati condivisi centralmente, come un database.

Answer 3

Sono d'accordo con Stevendick: può darsi che tu sia fuori strada con il design. Per quanto riguarda l'ID sequenza o approcci simili, ti suggerisco di ottenere informazioni sulle architetture di messaggistica con Schemi di integrazione aziendale: progettazione, costruzione e distribuzione di soluzioni di messaggistica (di Gregor Hohpe y Bobby Woolf). È un ottimo libro, molti schemi utili ... Sono sicuro che le forze e il problema che stai affrontando sono ben descritti lì.