Wir verwenden ActiveMQ 5.2 als unsere Implementierung der Wahl und wir haben es vor einer Weile ausgewählt. Es funktioniert gut genug für unseren Gebrauch jetzt. Da es schon eine Weile her ist, habe ich mich gefragt, welche anderen Java Message Service-Implementierungen verwendet werden und warum? Sicherlich gibt es mehr als ein paar.Welche JMS-Implementierung verwenden Sie?
In einem der letzten Projekte, in denen ich war, verwendeten wir Sonic MQ. Gute allgemeine Implementierung mit guten Bindungen zu .NET.
Wir hatten ein wenig Skalierbarkeitsprobleme, aber ich muss zugeben, dass die Skalierbarkeitsanforderungen sehr streng waren: Wenn ich mich richtig erinnere, gab es zwischen den 200 verschiedenen Clients pro Sekunde etwa 20.000 Fehler um jede Nachricht gleichzeitig zu empfangen).
Ich habe JBossMQ verwendet, das mit JBoss App Server bis Version 4 geliefert wird, und das solide aber begrenzt ist. JBoss Messaging war der Ersatz, kommt mit JBossAS 5 und ist eine große Verbesserung.
ActiveMQ Ich habe eine echte Abneigung für. Die Entwickler scheinen sich für Leistung und Funktionen auf Kosten der Stabilität entschieden zu haben, und es ist phänomenal fehlerhaft. Da es sich um den JMS-Fabric für Geronimo handelt, mache ich mir Sorgen.
Unsere Erfahrung war, dass Version 3 und 5 für ActiveMQ deutlich besser als 4 sind. –
... in Sachen Buggy wollte ich tippen. –
Ich versuchte 5.1, als es herauskam, und fand heraus, dass die Spring-Integration auf sehr einfache und offensichtliche Weise unterbrochen wurde, während 5.0 in dieser Hinsicht gut funktionierte. Ich habe kein Vertrauen mehr in das Testprogramm von ActiveMQ. – skaffman
Wir verlassen uns auf AMQ (5.1) über das Camel-Framework, und es gab keine Probleme. AMQ 4 war etwas fischiger.
TIBCO EMS. Es ist ein kommerzieller Nachrichtendienst mit Java/JMS, C, .net und anderen Bindungen dafür.
Suns Open-Source-OpenMQ (https://mq.dev.java.net/). Sie können kostenlos und bezahlte Unterstützung für das gleiche erhalten.
Sehen Sie diesen Blogpost über einige Vergleiche mit ActiveMQ, etc - http://alexismp.wordpress.com/2008/06/06/openmq-the-untold-story/.
Ich habe gehört, dass OpenMQ stabiler ist.
ActiveMQ ist flexibler. wie in, können Sie es mit mehr Sprachen verwenden. Es gibt wahrscheinlich mehr Leute auf der Mailingliste von ActiveMQ als OpenMQ.
IBM WebSphere MQ 5 und 6 Aktive MQ 5.2.0
Auch Micro Queuemanager Schauen Sie sich bei http://codingjunky.com/page5/page4/page4.html Es ist klein, einfach zu installieren und für kleinere Projekte zu verwenden.
WebLogic JMS-Provider bei Verwendung von WebLogic. Funktioniert super.
Danke. Ist das jetzt noch gültig? Wir müssen eine Warteschlange in einer Weblogic-Umgebung implementieren. Ich denke, wenn ich ActiveMQ oder internen Weblogic JMS wählen sollte? – Jay
Wir verwenden SonicMQ, JBossMQ und den "Micro Broker" von Lotus Expeditor Integrator. Wir verwenden sie für verschiedene Zwecke:
-JBossMQ wird intern verwendet und kommuniziert von allen unseren Java EE-Anwendungen, die auf JBoss laufen. -Lotus Expeditor wird in "Remote Sites" verwendet, wo wir nur begrenzte Ressourcen und IT-Mitarbeiter haben -SonicMQ ist unser Messaging-Backbone, wir verwenden es für die Verbindung von zentralen Systemen, sondern auch um Remote-Systeme in ca. zu verbinden. 1000 Seiten.
Wir haben gute Erfahrungen mit allen von ihnen, aber unsere Erfahrung ist auch, dass Sie mit einer komplexeren Umgebung eine aktivere Verwaltung des Messaging-Systems durchführen müssen. Dies gilt insbesondere für SonicMQ auf unserer Website :-). Aus Performance-Sicht haben wir die besten Erfahrungen mit SonicMQ gemacht, vor allem im Queue-basierten persistenten Messaging.
Ich habe ActiveMQ in der Produktion für ein paar Jahre verwendet, aber ich war nie glücklich über seine Stabilität (speziell mit ihm Clustered-aktiviert). Nie nach dem Wechsel zu OpenMQ zurückgeschaut. Vielleicht möchten Sie in RabbitMQ oder ZeroMQ schauen.
Bevor Sie sich mit JMS beschäftigen, sollten Sie auch AMQP in Betracht ziehen - dies könnte ein neuer Standard sein. JMS-Provider, mit denen ich gearbeitet habe (in unterschiedlichem Maße):
TIBCO EMS - sehr schnell und robust, gute API-Unterstützung, Java-freundliche, native C-API existiert. Beste kommerzielle Wahl, die ich verwendet habe.
Websphere MQ (und seine JMS-Implementierung) - so, so. Pub/Sub nicht gerade schnell, viele Konfigurationsmöglichkeiten und Auswahlmöglichkeiten sind "seltsam" und übermäßig komplex aus der langen Geschichte dieses Produktes. Schauen Sie sich nur die Menge an Dokumentation ...
Solace JMS - einen sehr hohen Durchsatz (! der JMS-Broker in Hardware gebaut), gute Auswahl von Verbindungsprotokollen (MQTT, AMQP, XML über HTTP als Admin-Protokolle)
Fiorano MQ - verwendet agressive Marketing zu sein, aber viele Marktanteile verloren, Reif betrifft
Sonic MQ - festes Produkt, unterstützt auch einen C-API
Aktive MQ - wenn Sie mit einem hinwollen Open-Source-Produkt (kostengünstige Unterstützung, große Community, begrenzte Add-on-Produkte, begrenzte Enterprise-Funktionen) ist dies wahrscheinlich bly Ihre beste Wahl. Funktioniert out of the box und ist das Rückgrat mehrerer Tools wie zum Beispiel Apache Camel.
Was ist der Unterschied zwischen solace jms und tibco ems? Der Grund, warum ich frage, wir laufen tibco ems auf Trost hw, aber es ist tibco ems Broker. Ich glaube, Trost jms ist völlig anders. – sloven
Sind Sie sicher, dass Sie EMS auf einer Solace-Hardware ausführen? Das wäre eine seltsame Kombination. TIBCO EMS ist nur Software (es gibt eine andere Hardware-Version) und Solace ist standardmäßig Hardware (sie haben auch eine Software-VM zum Testen). Und ja, Solace JMS und TIBCO JMS (= EMS) sind verschieden - verschiedene Firmen, aber beide unterstützen die gleiche API (JMS) –
Yup ... Ich habe dieses Setup in * mehreren * Orten gesehen. Sie kaufen die Nachrichten infra (hw) von Solace und sie laufen tibco darüber ... Für alle Java-Anwendungen verwenden sie tibco-Bibliotheken und für jede wirklich niedrige Latenz schreiben sie C++, das Trost-System-Level-Zeug verwendet ... Ich denke, Sie rede über letzteres. Wenn Broker in hw gebaut wird, müssen Sie auf niedriger Ebene gehen, um damit zu interagieren, macht Sinn. – sloven
Gibt es Implementierungen, die so hoch skalieren können? – cdoe
@Mani: Ich habe nicht die Details über die genaue Konfiguration oder Architektur des Warteschlangensystems, das eingerichtet wurde, weil ich nicht Teil des Middleware-Entwicklerteams war, aber ja, wir erreichten diese Durchsatzraten mit Sonic MQ. Es dauerte mehrere Iterationen, verschiedene Hardware- und Warteschlangenkonfigurationsschemata auszuprobieren. –