Produkte: Die folgende Konfiguration kann von EI 6.2.0 bis EI 6.6.0 angewendet werden.
Haben Sie schon einmal einen langen Roadtrip gemacht, bei dem Sie hunderte Kilometer quer durch Europa durch verschiedene schöne Städte gefahren sind und die Kultur und das Essen genossen haben? Wenn ja, was machen Sie als Erstes, wenn Sie zurück sind und sich natürlich erst einmal über ein langes Wochenende ausgeruht haben? Eventuell bringen Sie Ihr Auto in eine Werkstatt, um das Motoröl oder die Batterien überprüfen zu lassen. Sie werden wahrscheinlich sichergehen wollen, dass mit dem Auto alles in Ordnung ist und es immer noch zu 100 Prozent verkehrssicher ist. Wenn wir ein Musikinstrument lange genug spielen, muss es auch irgendwann neu gestimmt werden, damit es weiterhin so schön klingen kann, wie es soll.
Ähnlich verhält es sich mit IT-Systemen und -Produkten, die ebenfalls regelmäßig gewartet werden müssen. Und wenn Sie das nicht proaktiv tun, werden Sie die Probleme erst bemerken, wenn es zu spät ist. Normalerweise denken wir Menschen nicht allzu viel über reibungslos laufende Dinge nach und werden erst aktiv, wenn etwas nicht mehr funktioniert. Aber wie sagte einst ein weiser Mann:
„Man sollte das Dach reparieren, wenn die Sonne scheint“
John. F. Kenedy (1917-1963)
Wat ist JMS?
JMS steht für Java Message Service. Mit JMS in WSO2 EI können Sie Nachrichten ganz einfach an Warteschlangen und Themen jedes JMS-Dienstes, der die JMS-Spezifikation implementiert, senden und von dort empfangen. Mit JMS können Sie Nachrichten in den Warteschlangen und Themen jedes Message Brokers veröffentlichen. Die am häufigsten verwendeten Message Broker im EI sind ActiveMQ, RabbitMQ und WSO2s eigener Message Broker.
Bei komplexen Integrationsszenarien müssen Sie oft das Guaranteed Message Delivery Pattern implementieren, bei dem Sie sicherstellen müssen, dass die Nachricht nicht verloren geht. Eine Möglichkeit zur Implementierung dieses Musters ist die Verwendung von Warteschlangen und Themen. So können Nachrichten im Falle eines Verbindungsfehlers oder eines anderen Problems wiederhergestellt werden.
Mit dem steigenden Bedarf an der Implementierung von Diensten, die einen zuverlässigen Nachrichtenaustausch garantieren, steigt auch die Zahl der JMS-basierten Dienste. Wenn zu viele Dienste den JMS-Transport nutzen, müssen wir nach einer Weile Feinabstimmungen entsprechend unseren Bedürfnissen vornehmen. Die Standardeinstellungen reichen dafür einfach nicht aus.
Wie kann die Anzahl der JMS-Threads erhöht werden?
Es gibt viele Möglichkeiten, die Kapazität des EI zu erhöhen, um mehr JMS-basierte Verbindungen verarbeiten zu können. An dieser Stelle werden wir aber nur eine davon aufzeigen: die Erhöhung der Anzahl der JMS-Threads. Mit dieser Konfiguration stehen Ihnen genügend JMS-Threads zur Verfügung, um die Nachrichten aus den Warteschlangen zu verarbeiten. Die maximale Anzahl von JMS-Proxies, die gleichzeitig ausgeführt werden können, wird durch die diesen Eigenschaften zugewiesenen Werte bestimmt.
Sie können einen Dateinamen jms.properties im Ordner <EI_HOME>/conf des Produkts erstellen.
lst_t_core=200
lst_t_max=250
snd_t_core=200
snd_t_max=250
Der Standardwert dieser Attribute beträgt nur 20. Wenn Sie nicht explizit einen Wert festlegen, werden die Standardwerte automatisch zugewiesen. WSO2 bietet eine einfache Methode, um zu berechnen, was in diese Eigenschaften eingefügt werden soll.
lst_t_core > Total number of consumers + 20
lst_t_core < lst_t_ma
xsnd_tsnd_t_core > Total number of consumers + 20
snd_t_core < snd_t_max
Sie können die Gesamtzahl der Verbraucher nach folgender Formel berechnen
Gesamtzahl der Verbraucher = transport.jms.MaxConcurrentConsumers * Anzahl der JMS-Proxies
(Sie finden den Wert von transport.jms.MaxConcurrentConsumers in <EI_HOME>/conf/axis2/axis2.xml unter JMS-Listener-Transportkonfiguration. Falls nicht vorhanden, können Sie diesen Wert dort definieren.)
Nachdem Sie alle Einstellungen vorgenommen haben, müssen Sie den EI neu starten, damit die Einstellungen wirksam werden.
Fazit
JMS-basierte Lösungen werden aufgrund der einfachen Implementierung von Guaranteed Message Delivery und Message Roll Back Enterprise Integration Patterns immer verbreiteter. Um den Failover-Mechanismus von JMS-basierten Diensten im WSO2 Enterprise Integrator zu nutzen, müssen wir den Blockiermodus im Call Mediator verwenden. So können wir die Nachricht aufbewahren und wiederherstellen, wenn ein Verbindungsversuch mit dem Backend-System fehlschlägt.
Standardmäßig ist das Limit für diese JMS-Verbindungen in den Produkteinstellungen sehr niedrig angesetzt. Dieser Blog hebt einige Schritte hervor, mit denen Sie die Leistung von JMS-Proxy-Diensten verbessern können, indem Sie die zugrundeliegende Anzahl von Threads erhöhen, die zu diesem Zweck zugewiesen werden. Diese Einstellungen sollten am besten proaktiv oder vor einer Produktionseinführung vorgenommen werden, um Fehler zu vermeiden.
Zu verwirrend? Probieren Sie Connext oder Connext Go aus
Wenn Sie sich die Mühe ersparen wollen, diese Konfigurationen selbst vorzunehmen, dann können Sie unser Produkt CONNEXT (Platform as a service) ausprobieren. Wenn Sie CONNEXT verwenden, kümmert sich Yenlo um alle Einstellungen und Konfigurationen. Sie brauchen sich um nichts zu kümmern. Lehnen Sie sich einfach zurück, entspannen Sie sich und bauen Sie die Integrationen weiter aus.