La coda JMS è piena

Question

La mia applicazione Java EE invia JMS alla coda continuamente, ma a volte l'applicazione consumer JMS ha smesso di ricevere JMS. Rende la coda JMS molto grande anche piena, che comprime il server. Il mio server è JBoss o Websphere. I server delle applicazioni forniscono una strategia per rimuovere i messaggi JMS "timeout"?

Qual è la strategia per gestire una coda JMS di grandi dimensioni? Grazie!

Answer 1

Con qualsiasi messaggistica asincrona è necessario affrontare il problema "produttore veloce/consumatore lento". Ci sono diversi modi per affrontarlo.

1. Aggiungi consumatori. Con WebSphere MQ è possibile attivare una coda in base alla profondità. Alcuni negozi usano questo per aggiungere nuove istanze di consumo man mano che la coda aumenta. Quindi quando la profondità della coda inizia a diminuire, i consumatori extra muoiono. In questo modo, i consumatori possono essere fatti scalare automaticamente per adattarsi ai carichi variabili. In genere altri broker hanno funzionalità simili.
2. Rende la coda e il file system sottostante veramente grandi. Questo metodo tenta di assorbire i picchi del carico di lavoro interamente nella coda. In fin dei conti, in fin dei conti, è stato progettato in primo luogo. Il problema è che non si adatta bene e devi allocare il disco che il 99% delle volte sarà quasi vuoto.
3. Scadono vecchi messaggi. Se i messaggi hanno una scadenza impostata, puoi farli pulire. Alcuni broker JMS lo faranno automaticamente mentre su altri potrebbe essere necessario sfogliare la coda per fare in modo che i messaggi scaduti vengano cancellati. Il problema è che non tutti i messaggi perdono il loro valore commerciale e diventano idonei per la scadenza. La maggior parte dei messaggi fire-and-forget (log di audit, ecc.) Rientrano in questa categoria.
4. Riavviare il produttore. Quando la coda si riempie, nulla può inserirvi nuovi messaggi. In WebSphere MQ l'applicazione di produzione riceve quindi un codice di ritorno che indica che la coda è piena. Se l'applicazione distingue tra errori fatali e transitori, può fermarsi e riprovare.

La chiave per implementare con successo uno di questi è che il sistema sia autorizzato a fornire errori "soft" a cui l'applicazione risponderà. Ad esempio, molti negozi aumentano il parametro MAXDEPTH di una coda la prima volta che ottengono una condizione QFULL. Se la profondità della coda supera la dimensione del file system sottostante, il risultato è che al posto di un errore "soft" che influisce su una singola coda il file system si riempie e l'intero nodo è interessato. È MOLTO meglio ottimizzare il sistema in modo che la coda raggiunga MAXDEPTH ben prima che il file system si riempia, ma poi anche strumentando l'app o altri processi per reagire in qualche modo alla coda completa.

Ma qualunque cosa tu faccia, l'opzione # 4 qui sopra è obbligatoria. Indipendentemente dalla quantità di dischi allocati o dal numero di istanze consumer distribuite o dalla velocità di scadenza dei messaggi, è sempre possibile che i tuoi consumatori non tengano il passo con la produzione dei messaggi. Quando ciò accade, la tua app produttrice dovrebbe rallentare o alzare un allarme e fermarsi o fare qualcosa di diverso dall'impiccagione o dalla morte. La messaggistica asincrona è solo asincrona fino al punto in cui si esaurisce lo spazio per accodare i messaggi. Dopodiché le tue app sono sincrone e devono gestire con garbo la situazione, anche se ciò significa chiuderlo (con grazia).

Answer 2

Sicuro!

http://download.oracle.com/docs/cd/E17802_01/products/products/jms/javadoc-102a/index.html Message#setJMSExpiration(long) fa esattamente quello che vuoi.