Wie kann sichergestellt werden, dass die Nachricht aus der JMS-Warteschlange an den externen WebService (CXF) übermittelt wird?

8

Die Frage

Wie sollte man ActiveMQ und <flow> in Mule ESB 3.2 konfigurieren, um sicherzustellen, dass die aus der Warteschlange gezogene Nachricht korrekt von external CXF service ?

behandelt wird

Szenario

Ich habe einen CXF-Endpunkt, der eingehende Nachrichten so schnell wie möglich empfangen und an drei externe Dienste übertragen soll. Nennen wir sie EX1, EX2, EX3. Dies ist dank der in Mule 3.x eingeführten Komponente <all> relativ einfach.

Die wichtigste Anforderung der gesamten Lösung besteht darin, sicherzustellen, dass jede empfangene Nachricht an alle drei CXF-Dienste übermittelt wird. Wir hatten also die Idee, jede eingehende Nachricht in Persistent JMS queues (Q1, Q2, Q3) zu schreiben. Nachdem die Nachricht aus der Warteschlange Qn gelesen wurde, wird sie direkt an den entsprechenden EXn-Endpunkt und somit - externen Dienst übertragen.

Konfiguration

(Ich kann die vollständige Konfiguration auf Anfrage bereitstellen)

Wir haben den ActiveMQ-Broker wie hier hier konfiguriert und mit unserer <flow> config verdrahtet. Alles scheint wie erwartet zu funktionieren. Ich habe JConsole mit meiner Anwendung verbunden, damit ich sehen kann, dass die Nachrichten vom Typ PERSISTENT sind und sie in richtigen Warteschlangen landen. Wenn alles glatt läuft - Nachrichten werden von allen drei Diensten EXn empfangen.

Tests

Das Problem tritt auf, wenn wir einen der Dienste ausschalten, sagen wir EX2, und starten den gesamten Server neu, um einen Fehler zu simulieren. Die Nachricht endet verloren (Ich denke, es ist nicht so hartnäckig, nicht wahr?). Das Merkwürdigste ist - Wenn wir 10 Nachrichten gesendet haben, wenn der EX2 ausgefallen ist, werden nach dem Serverneustart 9 von ihnen ordnungsgemäß neu geliefert! Also denke ich, dass vielleicht nur 9 von diesen 10 Nachrichten richtig eingereiht wurden, während die eine immer wieder neu geliefert wurde, als der Server ausfiel.

Das lässt mich denken, dass der CXF-Endpunkt nicht mit Transaktionsunterstützung behandelt wird, was ich ehrlich gesagt nicht verstehen kann. Immerhin kann ich sehen, dass sich die Nachricht in der Warteschlange befindet, wenn versucht wird, sie erneut zuzustellen. Daher sollte sie beibehalten werden. Es ist eindeutig nicht, aber warum?

Meine eigenen Versuche Ich habe einige Dinge ausprobiert, von denen keine funktioniert hat. Immer geht eine Nachricht verloren.

  1. Keine <jms:transaction /> -Tags in den Flows verwenden - hat nicht funktioniert
  2. Starten der JMS-Transaktion nach Erhalt der Nachricht, Beitritt beim Senden an <cxf:jaxws-client />
  3. Die Verwendung von XA mit JBoss und <xa-transaction /> - funktionierte nicht
  4. Bereitstellung von <default-exception-strategy> config - Wenn ich mich erinnere, machte es die Dinge am schlimmsten

Jede Hilfe ist willkommen, danke.

KONFIG

AKTIVE MQ-KONFIGURATION

             

%Vor%

FLOW - Senden Sie eingehende Nachrichten an 3 Warteschlangen Qn

%Vor%

FLOW - behandelt die Zustellung von Qn zu EXn

%Vor%

ENDPOINTS - Deklaration der angegebenen Endpunkte

%Vor%     
ŁukaszBachman 24.01.2012, 14:21
quelle

3 Antworten

5

Der Konsum von JMS-Nachrichten in einer Transaktion ein Muss für die Lösung wie erwartet funktionieren: Wenn eine Ausnahme in der CXF Outbound-Phase auftritt, wird die JMS-Nachricht Ende-up zurückgerollt, dann nachgeliefert, eine neue CXF Rufauslösung <. / p>

Sie müssen sorgfältig die Nachlieferung Richtlinie für die ActiveMQ-Client konfigurieren, um zu oft genug zu wiederholen und vielleicht nicht zu schnell (exponentiell Back-off zum Beispiel). Sie möchten auch den DLQ entsprechend behandeln. ActiveMQ Client-Konfiguration mit Frühlings-Beans in Mule wird angezeigt: Ссылка

Achten Sie auch darauf, in Ihrer Konfigurationsfactory auf die richtige Broker-URL zu verweisen. Mit Ihrem Broker Namen esb-amq-broker , die Konfiguration Fabrik sollte sein:

%Vor%     
David Dossot 24.01.2012, 16:33
quelle
2

Ich weiß nicht, ob ich dir viel helfen werde, aber das sind ein paar Vorschläge bezüglich deines Problems:

  • Haben Sie versucht, einen anderen Transaktionsmanager als den mit Jboss bereitgestellten zu verwenden, würde ich vorschlagen, Atomikos für solche Tests zu verwenden
  • Wie David vorgeschlagen hat, scheinen Transaktionen der beste Ansatz zu sein, aber ein anderer Ansatz bestünde darin, eine explizite Bestätigungsrichtlinie zu verwenden ... Es könnte schwierig sein, einen Interceptor-ähnlichen Ansatz für Verbindungen zu bestimmten Endpunkten zu finden und zu senden die ack zurück zu deinem JMS-Server, schwierig mag sein aber es würde auf jeden Fall sicherstellen, dass die Nachricht korrekt zugestellt wurde ....

Viel Glück HTH Jerome

    
romje 09.02.2012 13:59
quelle
1

Nicht sicher, ob diese Überlegung hilft, aber was ist mit den Bestätigungsmodi? Ist es möglich, dass die Nachricht bereits gesendet wurde (im automatischen Bestätigungsmodus), aber noch nicht ordnungsgemäß vom Endpunkt des konsumierenden Service verarbeitet wurde?

Keine Ahnung, wie man explizite Bestätigung in diesem Szenario konfiguriert, aber vielleicht lohnt es sich weiter zu untersuchen.

    
Michael Ibbeken 10.02.2012 08:41
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Ist es sinnvoll, OpenGL 3.2 in modernen Spielen einzusetzen?