JBoss Seam - Messaggistica massiva nell'applicazione

Question

Attualmente sto armeggiando con un'applicazione che ha una configurazione che corrisponde alla seguente analogia di chat:

• Una chat è un oggetto tenuto in memoria e contiene un elenco di messaggi di chat
• Una chat viene resa in diverse finestre del browser e gli aggiornamenti vengono attirati con A4J: PUSH

La configurazione programmatica è simile alla seguente:un'istanza di un oggetto chat con i suoi messaggi è condivisa tra il componente seam con scope PAGE in sessioni diverse.Ora, quando qualsiasi sessione pubblica un nuovo messaggio, ad es.modifica l'oggetto chat, tutti i componenti seam dovrebbero essere informati del nuovo messaggio in modo che il nuovo stato possa essere inoltrato all'interfaccia utente su tutti i client.

Posso pensare a tre modi per raggiungere questo obiettivo:

1. Gli eventi di Seam con l'ID chat come parametro e poi ogni componente controlla l'ID e aggiorna o ignora il messaggio
2. Code JMS o un argomento JMS in cui ciascun componente è in ascolto con un filtro solo per la sua chat
3. un puro meccanismo di ascolto Java nell'oggetto chat condiviso, ad es.ogni componente della cucitura si registra e la notifica è Java puro e diretto

Per amor di discussione, supponiamo che il numero di chat sia elevato (decine di migliaia) e che il numero di utenti della chat sia piccolo (diciamo 2-10).

In che modo ciascuna scala valuta le prestazioni?Hai altri suggerimenti su come realizzarlo con Seam e ottenere buone prestazioni?

Per come la vedo io, (1) sarebbe integrato e pulito, ma alla fine notificheresti decine di migliaia di componenti dove solo pochi ne hanno effettivamente bisogno.Quindi probabilmente non si espanderà.

(2) sarebbe integrato e dipenderebbe solo dalle prestazioni del fornitore JMS (che può essere scambiato) e funzionerebbe anche in un ambiente cluster senza modifiche.Non sono sicuro delle prestazioni di JMS qui, ad es.qualche centinaio di messaggi al secondo e migliaia di ascoltatori con filtri diversi sono tanti oppure no?

(3) sarebbe veloce, perché verrebbero notificati solo i componenti richiesti e la notifica è Java pura e diretta.Tuttavia, potrebbero sorgere problemi di concorrenza/accesso perché viene eseguito qualcosa tra sessioni/componenti/thread incrociati.

Per (1) e (3) una soluzione che supporti il ​​clustering dovrebbe essere aggiunta manualmente, se necessario, a un certo punto.

Answer 1

Consiglierei 2).Consiglierei anche di eliminare JMS dall'equazione: anche se ti consentirà di cambiare fornitore di messaggistica, ti impedirà anche di utilizzare le funzionalità più avanzate del tuo sistema di messaggistica.Se stai utilizzando un database Oracle Q.A farebbe una scelta sensata (supporta JMS tra l'altro).Altrimenti consiglierei di utilizzare AMQP che dovrebbe essere disponibile tramite Messaggistica JBoss o una soluzione di terze parti come ConiglioMQ.

Poiché hai chiaramente un problema di messaggistica, dovresti optare per l'utilizzo di una soluzione di messaggistica.