ActiveMQ Ricevuta Messaggio Evento Solo un messaggio al secondo?

Question

Abbiamo costruito un infrastruttura applicativa basata su ActiveMQ.

Siamo in grado di inviare e ricevere messaggi bene, e per la maggior parte le cose sono abbastanza veloci e OK.

Tuttavia, abbiamo notato che se sottoponiamo un batch di messaggi "in una sola volta", dice 5.000 messaggi - che ActiveMQ otterrà i messaggi per l'applicazione 3rd party all'altro capo abbastanza rapidamente, e che questa applicazione elaborerà anche abbastanza rapidamente, e che sarà en Queue le risposte indietro al broker in fretta anche, dire meno di un minuto.

Ma per qualche ragione, il nostro EXE VB.NET che ha originato il messaggio in primo luogo appare solo per essere elaborazione dei messaggi di ritorno che riceve in modo irregolare, a volte facendo circa uno al secondo, a volte prendersi delle pause per un'ora o giù di lì e poi tornare a uno al secondo.

Origin (VB.NET EXE which we manage) 
    -> Broker  (which we manage)
        -> (3rd party app) 
            -> back to the same broker 
                -> back to the origin app.

Il ricevitore è in attesa del MessageListener evento dal codice C # scaricato da ActiveMQ forse 9 mesi fa:

Public Delegate Sub MessageListener(ByVal message As NMS.IMessage)
     Member of: NMS

Credo che ciò che sta accadendo è che ci dà MessageListener sola messaggi (NMS.IMessage) da masticare, e così questo è quello che noi trattati.

:

C'è qualche modo per dire "su un evento MessageListener, vedere se ci sono altri messaggi sulla coda in questo momento e tutti fanno"?

Answer 1

:

risulta, noi pensiamo di sapere un po 'di più adesso che cosa si tratta.

Quando il nostro VB.NET WinForms applicazione che utilizza la DLL ActiveMQ alla fine si blocca, che tende a fare un paio di volte a settimana, abbiamo un programma che utilizza il cane da guardia pslist Winternals e le utility PsKill a mietere lo zombie, e poi iniziamo una nuova connessione client.

In questo caso, utilizzando JConsole per analizzare il broker ci mostra che la sessione del zombie è ancora registrati, e così è il nuovo client fresco.

La mia teoria in questo momento è che quando AMQ vede entrambe le sessioni, si tenta di avviare la distribuzione di messaggi a entrambe le sessioni di stile round-robin. AMQ tenta di inviare il messaggio al zombie, che non risponde. Dopo un certo periodo di tempo (un secondo forse) AMQ si arrende e va alla prossima sessione della lista, il nuovo client fresco.

A un certo punto, lo stack TCP broker o probabilmente si accorge che lo zombie non ha mantenuto la sua connessione TCP attiva e dà in su; poi il funzionamento torna alla normalità.

Quindi la domanda diventa, come scrivere un client ActiveMQ che: a) non si muore o b) muore con grazia, chiudendo di essa la sessione nel processo?

Edit: l'aggiornamento alla prossima versione di ActiveMQ risolto questo. Inoltre abbiamo avuto una singola applicazione che fa l'invio e la ricezione, ma non è stato threadsafe - quindi se ha ricevuto mentre stava cercando di inviare questo ha causato il crash. Abbiamo ri-scritto come due applicazioni console, uno che ha inviato i dati e quello che ha ricevuto i dati. Nessun altro si blocca. Anche la versione precedente di ActiveMQ stavamo usando al momento non gestire crash con grazia, l'aggiornamento a 4.x risolto questo.

Answer 2

I suggerirei segnalato questo alla User Forum insieme forse sollevando una problema di supporto come questo suona come potrebbe essere qualche problema con il codice del client NMS e tutti gli sviluppatori NMS sono su quella lista e potrebbe rispondere