ActiveMQ Empfang der Nachricht Ereignis nur eine Nachricht pro Sekunde?

Question

Wir haben eine Anwendungsinfrastruktur auf Basis von ActiveMQ aufgebaut.

Wir können Nachrichten senden und empfangen ganz gut, und für die meisten Teile sind die Dinge ziemlich schnell und OK.

Wir haben jedoch festgestellt, dass, wenn wir einen Stapel von Nachrichten „auf einmal“ Eintragen, 5.000 Nachrichten sagen - dass ActiveMQ wird die Nachrichten an die 3rd-Party-Anwendung am anderen Ende ziemlich schnell bekommen, und dass diese Anwendung verarbeiten auch ziemlich schnell, und dass es en die Antworten auf die Broker-Warteschlange wieder schnell auch, sagt weniger als eine Minute.

Aber aus irgendeinem Grund, unsere VB.NET EXE, das die Nachrichten in erster Linie entstanden erscheint nur die Rückmeldungen zu verarbeiten es erratisch empfängt, manchmal über ein pro Sekunde zu tun, manchmal bricht eine Stunde nehmen oder so und dann geht zurück auf einen pro Sekunde.

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

Der Empfänger wartet auf den Fall von Message C # -Code von ActiveMQ heruntergeladen vielleicht vor 9 Monaten:

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

Ich denke, was passiert ist, dass Message gibt nur uns eine Nachricht (NMS.IMessage) zu kauen, und so ist das, was wir verarbeiten.

Gibt es eine Möglichkeit zu sagen: „Auf einem Message Ereignisse finden Sie bitte, ob es andere Nachrichten in der Warteschlange jetzt und tun sie alle“?

Answer 1

Es stellte sich heraus, denken wir, dass wir ein bisschen mehr wissen jetzt, worum es geht.

Wenn unsere VB.NET WinForms-Anwendung, die die ActiveMQ DLL schließlich stürzt verwendet, das es ein paar Mal in der Woche zu tun neigt, haben wir ein Watchdog-Programm, das das Winternals pslist und pskill Dienstprogramme verwendet den Zombie zu ernten, und dann starten eine neue Client-Verbindung.

Wenn dies geschieht, jconsole mit dem Makler analysieren zeigt uns, dass die Sitzung des Zombies noch registriert ist, und so ist die frischen neuen Kunden.

Meine Theorie ist im Moment, dass, wenn AMQ beide Sitzungen sieht, es Round-Robin-Stil der Verteilung von Nachrichten an den beiden Sitzungen zu starten versucht. AMQ versucht, die Nachricht an den Zombie zu senden, die nicht reagiert. Nach einer gewissen Zeit (eine Sekunde vielleicht) AMQ gibt auf und geht in die nächste Sitzung in der Liste, die neue frische Kunden.

An einem gewissen Punkt, der Makler oder die TCP-Stack bemerkt wahrscheinlich, dass der Zombie nicht gehalten hat, es ist TCP-Verbindung aktiv und es gibt auf; dann wird der Betrieb wieder normal.

So wird die Frage, wie ein ActiveMQ-Client schreiben, dass a) nicht stirbt oder b) stirbt anmutig, schließt er die Sitzung in dem Prozess nach unten?

Edit: Upgrade auf die nächste Version von ActiveMQ gelöst diese. Außerdem hatten wir eine einzige App tut dem Senden und Empfangen, aber es war nicht THREAD - also, wenn es empfangen wird, während es versucht, diese Abstürze verursacht zu senden. Dafür haben wir es als zwei Konsolenanwendungen, eine, die Daten und ein gesendet, die Daten empfangen. Keine Abstürze mehr. Auch die ältere Version von ActiveMQ wir waren zu der Zeit unter Verwendung von nicht abstürzt graziös handhaben, ein Upgrade, das 4.x gelöst.

Answer 2

Ich würde dies auf die User Forum empfehlen Berichterstattung zusammen mit vielleicht Unterstützung Ausgabe Anhebung wie das klingt wie könnte es einige Probleme mit dem NMS Client-Code sein und alle NMS-Entwickler sind auf dieser Liste und könnte antworten