In meinem letzten Blog habe ich erklärt, wie Sie WSO2 ESB und ActiveMQ für die garantierte Zustellung mit JMS-Transaktionen konfigurieren. Natürlich deshalb, weil Sie nicht wollen, dass Nachrichten im Cyberspace verloren gehen. In diesem Blog über garantierte Nachrichtenzustellungen möchte ich mich darauf konzentrieren, wie Sie Nachrichten bearbeiten, die nicht zugestellt werden können.
Im vorherigen Teil (1) des Blogs habe ich eine Beispielkonfiguration gezeigt, die unendlich viele Wiederholungsversuche vorsieht. Das kann jedoch eine Verschwendung von Ressourcen sein, wenn z.B. der Client für einige Zeit nicht erreichbar ist.
Die Lösung für dieses Problem besteht darin, die Nachrichten, die nicht zugestellt werden können, an eine andere Queue zu senden, eine so genannte Deadletterqueue. Dafür müssen Sie eine deadLetterStrategy konfigurieren.
Dabei handelt es sich um ein so genanntes Enterprise Integration Pattern. Diese Patterns sind für alle Unternehmen gleich und die WSO2ESB unterstützt alle diese Patterns. Genauer gesagt, gibt es auf der WSO2-Website eine spezielle Dokumentation dazu.
Ich werde Ihnen in diesem Blog erklären, wie Sie eine solche deadLetterStrategy mit WSO2ESB und ActiveMQ konfigurieren.
Um diese Konfiguration einzurichten, werden wir mit der Konfiguration aus meinem vorherigen Blog fortfahren.
Als erstes fügen wir dem folgenden Abschnitt in der Konfigurationsdatei Axis2.xml <ESB_HOME/repository/conf/axis2> eine Reihe von Parametern hinzu:
<!--Uncomment this and configure as appropriate for JMS transport support, after setting up your JMS environment (e.g. ActiveMQ) --> <transportReceiver class="org.apache.axis2.transport.jms.JMSListener" name="jms"> <parameter name="myQueueConnectionFactory"> <parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter> <parameter name="java.naming.provider.url">tcp://localhost:61616</parameter> <parameter name="transport.jms.ConnectionFactoryJNDIName>QueueConnectionFactory</parameter> <parameter name="transport.jms.ConnectionFactoryType">queue</parameter> <parameter name="transport.jms.SessionTransacted">true</parameter> <parameter name="transport.jms.SessionAcknowledgement">CLIENT_ACKNOWLEDGE</parameter> <parameter name="redeliveryPolicy.redeliveryDelay">1000</parameter> <parameter name="redeliveryPolicy.maximumRedeliveries">-1</parameter> <parameter name="transport.jms.CacheLevel">consumer</parameter> </parameter>
Fügen Sie die folgenden Parameter zu diesem Abschnitt hinzu:
<parameter name="redeliveryPolicy.initialRedeliveryDelay">1000</parameter> <parameter name="redeliveryPolicy.backOffMultiplier">3</parameter> <parameter name="redeliveryPolicy.useExponentialBackOff">true</parameter>
Erklärung
- redeliveryPolicy.initialRedeliveryDelay: die Zeit (in Millisekunden) zwischen der ersten Zustellung und dem ersten erneuten Zustellungsversuch.
- redeliveryPolicy.backOffMultiplier: multipliziert die Verzögerung der erneuten Zustellung zwischen den einzelnen Zustellungsversuchen.
- redeliveryPolicy.useExponentialBackOff: aktiviert oder deaktiviert das exponentielle Backoff unter Verwendung des im Parameter redeliveryPolicy.backOffMultiplier festgelegten Wertes.
Ändern Sie den Wert des folgenden Parameters:
:<parameter name="redeliveryPolicy.maximumRedeliveries">3</parameter>
Hinweis: Vergessen Sie nicht, den ESB neu zu starten, da diese nur beim Start geladen werden.
Wir haben jetzt eine Redelivery Policy konfiguriert, die folgendermaßen funktioniert:
- Nach dem ersten Zustellungsversuch gibt es eine Verzögerung von 1 Sekunde, bevor der zweite Versuch erfolgt.
- Vom zweiten zum dritten Versuch gibt es eine Verzögerung von 3 Sekunden.
- Zwischen dem dritten und dem vierten Versuch liegt eine Verzögerung von 9 Sekunden.
- Nach 4 Zustellversuchen wird die Nachricht in die Deadletter-Queue verschoben.
ActiveMQ hat standardmäßig eine Deadletter-Queue, die ActiveMQ.DLQ genannt wird. Alle nicht zustellbaren Nachrichten werden an diese Queue gesendet.
Wie Sie sich vorstellen können, kann dies jedoch schwierig zu verwalten sein, wenn verschiedene Nachrichten alle in derselben Queue landen.
Individuelle Dead-Letter-Strategie
Dieses Problem kann gelöst werden, wenn Sie eine individualDeadLetterStrategy konfigurieren. Dies geschieht in der activemq.xml-Konfiguration. In der Konfigurationsdatei activemq.xml finden Sie den folgenden Abschnitt mit Parametern:
<destinationPolicy> <policyMap> <policyEntries> <policyEntry topic=">" > <!-- The constantPendingMessageLimitStrategy is used to prevent slow topic consumers to block producers and affect other consumers by limiting the number of messages that are retained For more information, see: http://activemq.apache.org/slow-consumer-handling.html --> <pendingMessageLimitStrategy> <constantPendingMessageLimitStrategy limit="1000"/> </pendingMessageLimitStrategy> </policyEntry> </policyEntries> </policyMap> </destinationPolicy>
Ersetzen Sie diese durch die folgende Konfiguration:
<destinationPolicy> <policyMap> <policyEntries> <policyEntry queue=">"> <deadLetterStrategy> <individualDeadLetterStrategy queuePrefix="DLQ." useQueueForQueueMessages="true"/> </deadLetterStrategy> </policyEntry> </policyEntries> </policyMap> </destinationPolicy>
Erklärung
Mit dieser Konfiguration wird eine Deadletter-Queue mit dem Präfix „DLQ.“ für jede Queue erstellt, die eine Nachricht enthält, die nicht zugestellt werden kann. So können Sie die Nachrichten im Auge behalten und es ist einfacher, Nachrichten aus der DLQ zu holen, da wir sie noch zustellen müssen. In meinem nächsten Blog werde ich Ihnen von der Überwachung der Wiederzustellungsrichtlinie erzählen.
Falls Sie Fragen zu diesem Blogpost haben, kontaktieren Sie uns über den Kommentarbereich dieses Blogs. Sehen Sie sich auch unsere WSO2 Tutorials, Webinare oder White Papers an, um weitere technische Informationen zu erhalten. Benötigen Sie Unterstützung? Wir bieten WSO2-Produktsupport, WSO2-Entwicklungssupport, WSO2-Betriebssupport und WSO2-Trainingsprogramme.
