Für garantierte Nachrichtenreihenfolge, Lastenverteilung und Ausfallsicherung
Ein Nachrichtenübermittlungssystem mit garantierter Zustellung gewährleistet die Übermittlung der Nachricht vom Absender an den Empfänger, selbst wenn dieser offline ist. WSO2 Micro Integrator kann verwendet werden, um ein Nachrichtensystem mit garantierter Zustellung zusammen mit einem Nachrichtenbroker aufzubauen.
Diese Funktionalität steht natürlich auch im WSO2 Enterprise Integrator zur Verfügung, aber wir werden den Micro Integrator (auch bekannt als MI) erwähnen, da es sich um eine neuere Version handelt.
WSO2 MI bietet sofort einsatzbereite Lösungen für die Integration mit unterschiedlichen Anbietern von Nachrichtenbrokern. Einer der populärsten und als Open-Source verfügbaren Nachrichtenbroker ist ActiveMQ. Zusätzlich zur normalen Nachrichtenbroker-Funktionalität bietet ActiveMQ erweiterte Funktionen zur Implementierung verschiedener Anwendungsfälle bei der asynchronen Nachrichtenübermittlung
In einem unserer früheren Blog-Beiträge haben wir die „Exklusiver Konsument“-Funktion von ActiveMQ besprochen, um die Reihenfolge der Nachrichten bei der garantierten Zustellung beizubehalten. In diesem Blog-Beitrag werden wir die von ActiveMQ bereitgestellte Funktion „Nachrichtengruppen“ diskutieren.
Nachrichtengruppen
Die Funktion „Nachrichtengruppen“ ist eine Erweiterung der Funktion „Exklusiver Konsument“. Der JMSXGroupID-Header wird verwendet, um die Nachrichten zu gruppieren. Dadurch sind wir in der Lage, Anwendungsfälle wie die garantierte geordnete Zustellung, die Lastenverteilung zwischen mehreren Konsumenten sowie die hohe Verfügbarkeit/Ausfallsicherheit von Konsumenten umzusetzen.
ActiveMQ verwendet den JMSXGroupID-Header-Wert, um zu bestimmen, an welchen Konsumenten die Nachricht gesendet werden soll. ActiveMQ ordnet Konsumenten auf der Grundlage dieses Header-Wertes Nachrichtengruppen zu. Wenn einer Nachrichtengruppe kein Konsument zugeordnet ist, wird ein Konsument aus verfügbaren Konsumenten ausgewählt. Bis der ausgewählte Konsument offline geht, werden Nachrichten mit derselben Nachrichtengruppe (JMSXGroupID) an den ausgewählten Konsumenten zugestellt.
Sobald ein ausgewählter Konsument offline geht, nimmt AcitveMQ einen anderen Konsumenten auf, der keiner Nachrichtengruppe zugeordnet ist. Sollte es einen solchen Konsumenten nicht geben, wählt es aus jedem verfügbaren Konsumenten aus, der möglicherweise bereits einer Nachrichtengruppe zugeordnet ist
In diesem Blog-Beitrag werden wir diese Funktion mit WSO2 MI als Nachrichtenproduzent und -Konsument bewerten. Hier verwenden wir eine REST-API, die als JMS-Produzent fungiert, sowie zwei JMS-Proxys als JMS-Konsument. Sie können natürlich auch einen Proxy verwenden, um als JMS-Produzent zu agieren. Proxys sind in der Lage, eine JMS-Warteschlange abzuhören (natürlich zusätzlich zu anderen Transporten).
Diese REST-API würde XML-Nutzdaten akzeptieren und auf der Grundlage eines Nutzdatenattributs den JMSXGroupID-Header auffüllen und die Nutzdaten in der Warteschlange veröffentlichen. Beide JMS-Konsumenten würden die Nachrichten aus derselben Warteschlange konsumieren. Wir werden bewerten, wie ActiveMQ Nachrichten auf Grundlage des JMSXGroupID-Header-Wertes zwischen den Konsumenten versendet
Wir haben verwendet
– WSO2 MI 4.1.0
-ActiveMQ 5.15.12
Keep in mind that this will work on the Enterprise Integrator as well!
Konfigurieren von WSO2 EI mit ActiveMQ zum Veröffentlichen und Konsumieren von Nachrichten
Wir werden die Installation von WSO2 und ActiveMQ nicht vollständig beschreiben . Sehen Sie sich andere Blogs von Yenlo zu diesem Thema an oder folgen Sie den Anweisungen in der WSO2-Dokumentation, um die Einrichtung zu konfigurieren
JMS-Produzent REST-API im EI erstellen
Diese API akzeptiert eine XML-Nachricht und veröffentlicht die Nachricht zusammen mit dem JMS-Header JMSXGroupID in der Warteschlange „queue1“. Der Wert dieses Headers wird aus den Nutzdaten eingehender API-Anfragen extrahiert
<property expression="//groupID/text()" name="JMSXGroupID" scope="transport" type="STRING"/>In der Quellansicht sieht der Code so aus. Beachten Sie, dass wir einen Eigenschaftsgruppen-Vermittler verwenden, um das Design an die Seite dieses Blogs anzupassen.
<?xml version="1.0" encoding="UTF-8"?>
<api context="/publish" name="jms-publisher" xmlns="http://ws.apache.org/ns/synapse">
<resource methods="POST" uri-template="/message">
<inSequence>
<log level="custom">
<property name="LOG" value="Message received. Publish to queue."/>
</log>
<propertyGroup>
<property expression="//groupID/text()" name="JMSXGroupID" scope="transport" type="STRING"/>
<property name="FORCE_SC_ACCEPTED" scope="axis2" type="STRING" value="true"/>
<property name="OUT_ONLY" scope="default" type="STRING" value="true"/>
<property name="messageType" scope="axis2" type="STRING" value="application/xml"/>
<property name="QueueName" scope="default" type="STRING" value="queue1"/>
</propertyGroup>
<header expression="concat('jms:/',get-property('QueueName'),'?transport.jms.ConnectionFactory=myQueueSender'')" name="To" scope="default"/>
<property action="remove" name="REST_URL_POSTFIX" scope="axis2"/>
<call>
<endpoint>
<default>
<timeout>
<duration>10000</duration>
<responseAction>fault</responseAction>
</timeout>
<suspendOnFailure>
<errorCodes>-1</errorCodes>
<initialDuration>0</initialDuration>
<progressionFactor>1.0</progressionFactor>
<maximumDuration>0</maximumDuration>
</suspendOnFailure>
<markForSuspension>
<errorCodes>-1</errorCodes>
<retriesBeforeSuspension>0</retriesBeforeSuspension>
</markForSuspension>
</default>
</endpoint>
</call>
</inSequence>
<outSequence/>
<faultSequence/>
</resource>
</api>
JMS-Consumer 1 im EI erstellen
Dieser Proxy fungiert als JMS-Konsument und hat sich bei der Warteschlange „queue1“ angemeldet. Sobald eine Nachricht konsumiert wird, werden die Nutzdaten und der JMXGroupID-Header-Wert protokolliert
<?xml version="1.0" encoding="UTF-8"?>
<proxy name="Alleenvooropmaak-jmsconsumer1" startOnLoad="true" transports="jms" xmlns="http://ws.apache.org/ns/synapse">
<target>
<inSequence>
<log level="full">
<property name="LOG" value="Consumer1 : Message consumed from queue."/>
<property expression="$trp: JMSXGroupID " name="groupID"/>
</log>
<log level="custom">
<property name="LOG" value="Consumer1 : Message processed. Send ACK to queue."/>
</log>
</inSequence>
<outSequence/>
<faultSequence>
<log level="full">
<property name="LOG" value="Consumer1 : Message processed. Send NACK to queue."/>
</log>
</faultSequence>
</target>
<parameter name="transport.jms.SessionAcknowledgement">CLIENT_ACKNOWLEDGE</parameter>
<parameter name="transport.jms.DestinationType">queue</parameter>
<parameter name="transport.jms.Destination">queue1</parameter>
<parameter name="transport.jms.ContentType">
<rules xmlns="">
<jmsProperty>contentType</jmsProperty>
<default>application/xml</default>
</rules>
</parameter>
<parameter name="transport.jms.SessionTransacted">true</parameter>
<parameter name="transport.jms.ConnectionFactory">myQueueListener</parameter>
<parameter name="transport.jms.CacheLevel">consumer</parameter>
</proxy>
JMS-Consumer 2 im EI erstellen
Dieser Proxy fungiert als JMS-Konsument und hat sich bei der Warteschlange „queue1“ angemeldet. Sobald eine Nachricht konsumiert wird, werden die Nutzdaten und der JMXGroupID-Header-Wert protokolliert
<?xml version="1.0" encoding="UTF-8"?>
<proxy name="jmsconsumer2" startOnLoad="true" transports="jms" xmlns="http://ws.apache.org/ns/synapse">
<target>
<inSequence>
<log level="full">
<property name="LOG" value="Consumer2 : Message consumed from queue."/>
<property expression="$trp: JMSXGroupID " name="groupID"/>
</log>
<log level="custom">
<property name="LOG" value="Consumer2 : Message processed. Send ACK to queue."/>
</log>
</inSequence>
<outSequence/>
<faultSequence>
<drop/>
</faultSequence>
</target>
<parameter name="transport.jms.SessionAcknowledgement">CLIENT_ACKNOWLEDGE</parameter>
<parameter name="transport.jms.DestinationType">queue</parameter>
<parameter name="transport.jms.Destination">queue1</parameter>
<parameter name="transport.jms.ContentType">
<rules xmlns="">
<jmsProperty>contentType</jmsProperty>
<default>application/xml</default>
</rules>
</parameter>
<parameter name="transport.jms.SessionTransacted">true</parameter>
<parameter name="transport.jms.ConnectionFactory">myQueueListener</parameter>
<parameter name="transport.jms.CacheLevel">consumer</parameter>
</proxy>
Testen der Einrichtung
Wir werden zwei Nachrichten mit dem Wert groupID gleich group1 und zwei weitere Nachrichten mit dem Wert groupID gleich group 2 senden
Oder, wenn Sie Curl verwenden möchten:
curl -k --location --request POST 'https://localhost:8253/publish/message' --header 'Content-Type: application/xml' --data '<groupID>group1</groupID>'
curl -k --location --request POST 'https://localhost:8253/publish/message' --header 'Content-Type: application/xml' --data '<groupID>group2</groupID>'
Um die Protokolle besser lesbar zu machen, habe ich einen Teil der Textfarbe geändert.
[2022-11-25 09:49:40,947] INFO {LogMediator} – {api:jms-publisher} LOG = Message received. Publish to queue.[2022-11-25 09:49:41,041] INFO {LogMediator} – {proxy:jmsconsumer1} To: , WSAction: urn:mediate, SOAPAction: urn:mediate, MessageID: ID:ip-172-31-39-100.eu-central-1.compute.internal-32983-1669364529898-9:3:1:1:1, Direction: request, LOG = Consumer1 : Message consumed from queue., groupID = group1, Envelope: <?xml version=’1.0′ encoding=’utf-8′?><soapenv:Envelope xmlns:soapenv=“http://schemas.xmlsoap.org/soap/envelope/“><soapenv:Body><groupID>group1</groupID></soapenv:Body></soapenv:Envelope>
[2022-11-25 09:49:41,041] INFO {LogMediator} – {proxy:jmsconsumer1} LOG = Consumer1 : Message processed. Send ACK to queue.
[2022-11-25 09:50:49,094] INFO {LogMediator} – {api:jms-publisher} LOG = Message received. Publish to queue.
[2022-11-25 09:50:49,238] INFO {LogMediator} – {proxy:jmsconsumer2} To: , WSAction: urn:mediate, SOAPAction: urn:mediate, MessageID: ID:ip-172-31-39-100.eu-central-1.compute.internal-32983-1669364529898-9:4:1:1:1, Direction: request, LOG = Consumer2 : Message consumed from queue., groupID = group2, Envelope: <?xml version=’1.0′ encoding=’utf-8′?><soapenv:Envelope xmlns:soapenv=“http://schemas.xmlsoap.org/soap/envelope/“><soapenv:Body><groupID>group2</groupID></soapenv:Body></soapenv:Envelope>
[2022-11-25 09:50:49,238] INFO {LogMediator} – {proxy:jmsconsumer2} LOG = Consumer2 : Message processed. Send ACK to queue.
Wie wir in den nachstehenden Konsumentenprotokollen sehen können, hat ActiveMQ den Konsumenten 1 für die Zustellung von Nachrichten mit groupID =group1 und den Konsumenten 2 für die Zustellung von Nachrichten mit groupID = group2 ausgewählt. Dann werden aufeinanderfolgende Nachrichten mit denselben groupIDs an die zugehörigen Konsumenten versandt.
Inaktiver Konsument 2
Lassen Sie uns nun sehen, wie sich die Nachrichtenübermittlung gestaltet, wenn ein Konsument offline ist. In unserem Fall deaktivieren wir Konsument 2, während Konsument 1 aktiv ist. Sie können einen JMS-Proxy über das Micro Integrator Dashboard oder die Verwaltungs-API deaktivieren (oder die Bereitstellung des Proxys beenden).
[2022-11-25 10:12:25,406] INFO {ServiceTaskManager} – JMS Polling server task stopped for service jmsconsumer2 MessageListenerTask{workerState=3, idleExecutionCount=51, idle=true, connected=true, listenerPaused=false, connectionReceivedError=false}[2022-11-25 10:12:26,083] INFO {ServiceTaskManager} – Task manager for service : jmsconsumer2 shutdown
[2022-11-25 10:12:26,084] INFO {JMSListener} – Stopped listening for JMS messages to service : jmsconsumer2
[2022-11-25 10:12:26,084] INFO {ProxyService} – {proxy:jmsconsumer2} Stopped the proxy service : jmsconsumer2
Nach der Deaktivierung des Konsumenten 2, senden Sie eine Nachricht mit ‚groupID=group2‘. Diese Nachricht wird nun an Konsumenten 1 versandt. Da kein Konsument mit dieser groupID verbunden ist, wählt ActiveMQ einen anderen verfügbaren Konsumenten aus. In unserem Fall ist das Konsument 1.
[2022-11-25 10:15:09,478] INFO {LogMediator} – {proxy:jmsconsumer1} To: , WSAction: urn:mediate, SOAPAction: urn:mediate, MessageID: ID:ip-172-31-39-100.eu-central-1.compute.internal-36290-1669366889587-9:5:1:1:1, Direction: request, LOG = Consumer1 : Message consumed from queue., groupID = group2, Envelope: group2
[2022-11-25 10:15:09,478] INFO {LogMediator} – {proxy:jmsconsumer1} LOG = Consumer1 : Message processed. Send ACK to queue.
Mal schauen, was passieren würde, wenn Konsument 2 wieder online geht. Aktivieren Sie den Konsumenten 2 über die Verwaltungskonsole und senden Sie eine Nachricht mit groupID=group 1 und mit groupID=group 2
[2022-11-25 10:16:51,513] INFO {JMSListener} – Connection attempt: 1 for JMS Provider for service: jmsconsumer2 was successful![2022-11-25 10:16:51,517] INFO {ServiceTaskManager} – Task manager for service : jmsconsumer2 [re-]initialized
[2022-11-25 10:16:51,527] INFO {ServiceTaskManager} – JMS Polling task activated with state: 1 for service jmsconsumer2
[2022-11-25 10:16:52,519] INFO {JMSListener} – Started to listen on destination : queue1 of type queue for service jmsconsumer2
[2022-11-25 10:16:52,520] INFO {ProxyService} – {proxy:jmsconsumer2} Started the proxy service : jmsconsumer2
[2022-11-25 10:17:02,386] INFO {LogMediator} – {api:jms-publisher} LOG = Message received. Publish to queue.
[2022-11-25 10:17:02,742] INFO {LogMediator} – {proxy:jmsconsumer1} To: , WSAction: urn:mediate, SOAPAction: urn:mediate, MessageID: ID:ip-172-31-39-100.eu-central-1.compute.internal-36290-1669366889587-9:6:1:1:1, Direction: request, LOG = Consumer1 : Message consumed from queue., groupID = group2, Envelope: group2
[2022-11-25 10:17:02,743] INFO {LogMediator} – {proxy:jmsconsumer1} LOG = Consumer1 : Message processed. Send ACK to queue.
Wie wir im Protokoll sehen, werden beide Nachrichten an Konsument 1 gesendet. Da beide Nachrichtengruppen im vorherigen Schritt von ActiveMQ dem Konsumenten 1 zugeordnet wurden
Eine Änderung vornehmen
Sehen wir uns nun an, wie wir ActiveMQ anweisen können, einen anderen Konsumenten für eine Nachrichtengruppe auszuwählen, wenn die Nachrichtengruppe bereits einem Konsumenten zugeordnet ist (In unserem Fall sind beide Nachrichten der Nachrichtengruppe dem Konsumenten 1 zugeordnet, und wir wollen die Nachricht der Gruppe 2 wieder an den Konsumenten 2 weiterleiten). Dies kann durch Senden einer Nachricht mit JMSXGroupSeq-Header mit negativem Wert erfolgen.
Lassen Sie uns nun unseren JMS-Publisher aktualisieren, um JMSXGroupSeq auf -1 zu setzen, wenn eingehende Anfragen den Transportparameter closeGroup haben.
Als Quellcode:
<?xml version="1.0" encoding="UTF-8"?>
<api context="/publish" name="jms-publisher" xmlns="http://ws.apache.org/ns/synapse">
<resource methods="POST" uri-template="/message">
<inSequence>
<log level="custom">
<property name="LOG" value="Message received. Publish to queue."/>
</log>
<property expression="//groupID/text()" name="JMSXGroupID" scope="transport" type="STRING"/>
<filter regex="^true$" source="$trp:closeGroup">
<then>
<property name="JMSXGroupSeq" scope="transport" type="STRING" value="-1"/>
</then>
<else/>
</filter>
<property name="FORCE_SC_ACCEPTED" scope="axis2" type="STRING" value="true"/>
<property name="OUT_ONLY" scope="default" type="STRING" value="true"/>
<property name="messageType" scope="axis2" type="STRING" value="application/xml"/>
<property name="QueueName" scope="default" type="STRING" value="queue1"/>
<header expression="concat('jms:/',get-property('QueueName'),'?transport.jms.ConnectionFactory =myQueueSender')" name="To" scope="default"/>
<property action="remove" name="REST_URL_POSTFIX" scope="axis2"/>
<call>
<endpoint>
<default>
<timeout>
<duration>10000</duration>
<responseAction>fault</responseAction>
</timeout>
<suspendOnFailure>
<errorCodes>-1</errorCodes>
<initialDuration>0</initialDuration>
<progressionFactor>1.0</progressionFactor>
<maximumDuration>0</maximumDuration>
</suspendOnFailure>
<markForSuspension>
<errorCodes>-1</errorCodes>
<retriesBeforeSuspension>0</retriesBeforeSuspension>
</markForSuspension>
</default>
</endpoint>
</call>
</inSequence>
<outSequence/>
<faultSequence/>
</resource>
</api>
Senden Sie eine Nachricht mit groupID=group2 und dem Header closeGroup:true. Verwenden Sie entweder curl oder SoapUI.
curl -k –location –request POST ‚https://localhost:8253/publish/message‘ –header ‚Content-Type: application/xml‘ –header ‚closeGroup: true‘ –data ‚<groupID>group2</groupID>‘
Senden Sie dann einige Nachrichten der Gruppe 2. Wie in den Protokollen zu sehen ist, erreicht die erste Nachricht der Gruppe 2 mit closeGroup:true (d.h. JMSXGroupSeq = -1) den Konsumenten 1. Dadurch wurde jedoch die Nachrichtengruppe geschlossen, und folglich werden die Nachrichten der Gruppe 2 an einen anderen Konsumenten (Konsument 2) gesendet.
[2022-11-29 13:13:58,784] INFO {org.apache.axis2.transport.jms.JMSListener} – Connection attempt: 1 for JMS Provider for service: jmsconsumer2 was successful![2022-11-29 13:13:58,787] INFO {org.apache.axis2.transport.jms.ServiceTaskManager} – Task manager for service : jmsconsumer2 [re-]initialized
[2022-11-29 13:13:58,787] INFO {org.apache.axis2.transport.jms.ServiceTaskManager} – JMS Polling task activated with state: 1 for service jmsconsumer2
[2022-11-29 13:13:59,796] INFO {org.apache.axis2.transport.jms.JMSListener} – Started to listen on destination : queue1 of type queue for service jmsconsumer2
[2022-11-29 13:13:59,796] INFO {org.apache.synapse.core.axis2.ProxyService} – {proxy:jmsconsumer2} Started the proxy service : jmsconsumer2
[2022-11-29 13:14:21,202] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {api:jms-publisher} LOG = Message received. Publish to queue.
[2022-11-29 13:14:21,202] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {api:jms-publisher} Value = Hier
[2022-11-29 13:14:21,203] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {api:jms-publisher} To = jms:/queue1?transport.jms.ConnectionFactory=myQueueSender
[2022-11-29 13:14:21,203] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {api:jms-publisher} To: jms:/queue1?transport.jms.ConnectionFactory=myQueueSender, MessageID: urn:uuid:5404bea4-fea1-4d97-868f-1b6af1c155f5, correlation_id: 5404bea4-fea1-4d97-868f-1b6af1c155f5, Direction: request, Envelope: group2
[2022-11-29 13:14:21,273] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {proxy:jmsconsumer1} To: , WSAction: urn:mediate, SOAPAction: urn:mediate, MessageID: ID:ip-172-31-39-100.eu-central-1.compute.internal-39942-1669718798195-9:9:1:1:4, Direction: request, LOG = Consumer1 : Message consumed from queue., groupID = group2, Envelope: group2
[2022-11-29 13:14:21,273] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {proxy:jmsconsumer1} LOG = Consumer1 : Message processed. Send ACK to queue.
[2022-11-29 13:14:25,397] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {api:jms-publisher} LOG = Message received. Publish to queue.
[2022-11-29 13:14:25,398] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {api:jms-publisher} To = jms:/queue1?transport.jms.ConnectionFactory=myQueueSender
[2022-11-29 13:14:25,399] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {api:jms-publisher} To: jms:/queue1?transport.jms.ConnectionFactory=myQueueSender, MessageID: urn:uuid:6d92c98d-da75-4ea7-9a0a-7a64854b2752, correlation_id: 6d92c98d-da75-4ea7-9a0a-7a64854b2752, Direction: request, Envelope: group2
[2022-11-29 13:14:25,424] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {proxy:jmsconsumer2} To: , WSAction: urn:mediate, SOAPAction: urn:mediate, MessageID: ID:ip-172-31-39-100.eu-central-1.compute.internal-39942-1669718798195-9:10:1:1:4, Direction: request, LOG = Consumer2 : Message consumed from queue., groupID = group2, Envelope: group2
[2022-11-29 13:14:30,823] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {proxy:jmsconsumer2} LOG = Consumer2 : Message processed. Send ACK to queue.
[2022-11-29 13:14:36,282] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {api:jms-publisher} LOG = Message received. Publish to queue.
[2022-11-29 13:14:36,283] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {api:jms-publisher} To = jms:/queue1?transport.jms.ConnectionFactory=myQueueSender
[2022-11-29 13:14:36,283] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {api:jms-publisher} To: jms:/queue1?transport.jms.ConnectionFactory=myQueueSender, MessageID: urn:uuid:e21cb03f-0a52-4252-a3ce-218176e33363, correlation_id: e21cb03f-0a52-4252-a3ce-218176e33363, Direction: request, Envelope: group1
[2022-11-29 13:14:36,290] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {proxy:jmsconsumer1} To: , WSAction: urn:mediate, SOAPAction: urn:mediate, MessageID: ID:ip-172-31-39-100.eu-central-1.compute.internal-39942-1669718798195-9:3:1:1:5, Direction: request, LOG = Consumer1 : Message consumed from queue., groupID = group1, Envelope: group1
[2022-11-29 13:14:36,290] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {proxy:jmsconsumer1} LOG = Consumer1 : Message processed. Send ACK to queue.
[2022-11-29 13:14:40,485] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {api:jms-publisher} LOG = Message received. Publish to queue.
[2022-11-29 13:14:40,486] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {api:jms-publisher} To = jms:/queue1?transport.jms.ConnectionFactory=myQueueSender
[2022-11-29 13:14:40,486] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {api:jms-publisher} To: jms:/queue1?transport.jms.ConnectionFactory=myQueueSender, MessageID: urn:uuid:e1975933-c482-4651-8873-16b728300e47, correlation_id: e1975933-c482-4651-8873-16b728300e47, Direction: request, Envelope: group2
[2022-11-29 13:14:40,532] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {proxy:jmsconsumer2} To: , WSAction: urn:mediate, SOAPAction: urn:mediate, MessageID: ID:ip-172-31-39-100.eu-central-1.compute.internal-39942-1669718798195-9:4:1:1:5, Direction: request, LOG = Consumer2 : Message consumed from queue., groupID = group2, Envelope: group2
[2022-11-29 13:14:40,532] INFO {org.apache.synapse.mediators.builtin.LogMediator} – {proxy:jmsconsumer2} LOG = Consumer2 : Message processed. Send ACK to queue.
