[z/OS]

Einstellungen der Verbindungsfactory für ASF-MDBs, die WebSphere MQ als Messaging-Provider unter z/OS verwenden

Sie können verschiedene Einstellungen der Verbindungsfactory anpassen, um die Erstellung von Verbindungen und Sitzungen für MDB-Anforderungen zu steuern.

Einstellungen für Verbindungsfactory

Damit eine Anwendung und ein Server einem bestimmten Warteschlangenmanager mit Authentifizierungsparametern zugeordnet werden können, sind Anwendungen und Nachrichten-Listener-Ports an Verbindungsfactorys gebunden. Der Server verwendet dasselbe Verwaltungsmodell zur Überwachung von Nachrichten, die zwecks Übergabe bei MDBs eingehen, wie die Anwendung, die es einsetzt, um die Funktionalität von JMS zu nutzen. Nachrichten-Listener-Ports sind an eine Warteschlangenverbindungsfactory bzw. Topicverbindungsfactory sowie eine entsprechende Warteschlange bzw. ein entsprechendes Topic gebunden.

Zusätzlich zu den Einstellungen für den Messaging-Provider (z. B. Einstellungen für den Warteschlangenmanager) geben Sie auch die Eigenschaften von Verbindungs- und Sitzungspools an. Insbesondere für eine Verbindungsfactory müssen die maximale Anzahl von Verbindungen im Verbindungspool und die maximale Anzahl von Sitzungen im Sitzungspool unter verschiedenen Gesichtspunkten ausgewählt werden, je nachdem, ob Sie die Verbindungsfactory für einen Listener-Port und/oder eine Anwendung verwenden.

Einstellungen für maximale Anzahl von Verbindungen im Verbindungspool

Zuerst setzen Sie die maximale Anzahl von Verbindungen des Verbindungspools auf einen Wert, der zumindest der Summe der folgenden Werte entspricht, um zu vermeiden, dass auf eine JMS-Verbindung gewartet werden muss, weil ein von WebSphere Application Server definierter Grenzwert erreicht wurde:
Eine Verbindung für jede Message-driven Bean, die einem dieser Verbindungsfactory zugeteilten Listener-Port zugeordnet ist.
Eine MDB kann durch Ausführung ihrer Anwendungslogik in onMessage() eine JMS-Verbindung abrufen, beispielsweise wie folgt:
  • Die Nachricht an ein anderes Ziel weiterleiten oder eine Antwort senden
  • Ein Protokoll aktualisieren, ohne jedoch selbst JMS-Aufrufe durchzuführen

Jedenfalls muss für diese MDB der Wert '1' gesetzt werden, da diese Verbindung vom Listener-Port verwendet wird.

Wenn die onMessage()-Logik der MDB eine JMS-Verbindung abruft, wird die Anzahl der Servant-Worker-Threads zum Wert für die maximale Anzahl von Verbindungen addiert. Andernfalls ist die Addition zum Wert für die maximale Anzahl von Verbindungen für diese MDB-Anwendungskomponente nicht erforderlich.

Die maximale Anzahl von Verbindungen
Lokalisieren Sie zunächst den Wert für die bei einer einzigen Anwendungszuteilung abgerufene maximale Anzahl von Verbindungen (normalerweise '1'). Dazu müssen Sie alle Anwendungen überprüfen, die diese Verbindungsfactory verwenden. Multiplizieren Sie diesen Wert dann mit der Anzahl der Worker-Threads in einem Servant, um die maximale Anzahl von Verbindungen zu berechnen.
Anmerkung:
  • Beachten Sie, dass hier nur die Worker-Threads für einen einzigen Servant gezählt werden, denn jeder Servant erhält seine eigene Verbindungsfactory mit Verbindungs- und Sitzungspools.
  • Schließen Sie andere Nicht-MDB-Anwendungskomponenten, die diese Verbindungsfactory verwenden, um JMS-Aufrufe abzusetzen, ein. Unabhängig davon, wie viele MDB- oder Nicht-MDB-Anwendungskomponenten diese Verbindungsfactory verwenden, und vorausgesetzt, dass jede Komponente nur eine JMS-Verbindung pro Zuteilung verwendet, entspricht der Wert für die maximale Anzahl von Verbindungen der Anzahl der Worker-Threads (nicht der Anzahl der Anwendungen multipliziert mit der Anzahl der Servant-Worker-Threads).

Einstellungen für maximale Anzahl von Verbindungen im Sitzungspool

Für die Verarbeitungsvorgänge von MDB-Listener-Ports in allen typischen Fällen setzen Sie die maximale Anzahl von Verbindungen im Sitzungspool auf den Wert für die Anzahl der Worker-Threads in einem einzigen Servant.

Die Gründe sind folgende: JMS-Sitzungen werden nicht über mehrere Anwendungszuteilungen oder von der Listener-Portinfrastruktur gemeinsam genutzt, nicht einmal für Clients derselben Verbindungsfactory. Außerdem gibt es einen eindeutigen Sitzungspool für jede von der Verbindungsfactory abgerufene JMS-Verbindung (obwohl die Einstellungen für Pooleigenschaften nur einmal auf der Ebene der Verbindungsfactory angegeben werden).

Denkbar ist ein Szenario, in dem eine Verbindungsfactory von einem Listener-Port und einer Anwendung verwendet wird, wobei anzumerken ist, dass die Anwendung einen höheren Wert für die maximale Anzahl von Verbindungen im Sitzungspool benötigt. Dieser Umstand soll jedoch in diesem Kontext nicht weiter erörtert werden.

Wichtig: Sie sollten die gleichzeitigen MDB-Arbeitsvorgänge in einem Server nicht einschränken, indem Sie die maximal zulässige Anzahl der Verbindungen für diesen Sitzungspool auf einen kleineren Wert als die Anzahl der Servant-Worker-Threads setzen, da es in diesem Fall möglich ist, dass eine MDB-Arbeitsanforderung einem Servant zugeteilt wird, ohne dass eine Sitzung für die Verarbeitung der Nachricht verfügbar ist. Der Worker-Thread muss in diesem Fall warten, bis eine Sitzung verfügbar wird. Dabei werden wertvolle Worker-Thread-Ressourcen gebunden.

Sollen wenige oder viele Factorys verwendet werden?

Sie ziehen es möglicherweise vor, diese Berechnungen einfach zu halten, indem Sie z. B. für jede MDB eine separate Verbindungsfactory erstellen (in diesem Fall kann der Wert für die Eigenschaft "Maximale Anzahl von Verbindungen" einfach auf '1' gesetzt werden). Sie können es aber auch vorziehen, weniger Verwaltungsobjekte für Verbindungsfactorys zu verwalten.

Die Verbindungen und Sitzungen, die für die MDB-Verarbeitung verwendet werden, können nicht gemeinsam genutzt werden (d. h., sie können nur jeweils von einem Workflow verwendet werden). Deshalb dürfen Sie das Pooling nicht als Mittel einsetzen, um weniger Verbindungsfactorys zu verwenden. Mit anderen Worten, das Hinzufügen einer weiteren Verbindungsfactory verhindert nicht das Verbindungspooling, das ansonsten durch die Verarbeitungsprozesse der MDB-Listener-Ports ausgenutzt werden könnte.

Verbindungsfactorys - Beispiele

Szenario für Beispiel 1:
  • Jeder Servant hat 12 Worker-Threads. (Die Anzahl der Servants im Server ist nicht wichtig, da jeder Servant seine eigenen Pools hat.)
  • Listener-Port LP1 wird der Verbindungsfactory CF1 zugeordnet. Die Message-Driven Bean MDB1 wird LP1 zugeordnet. Der Anwendungscode onMessage() von MDB1 stellt eine neue Nachricht in eine Weiterleitungswarteschlange, und so hat MDB1 eine Ressourcenreferenz, die ebenfalls zu CF1 aufgelöst wird.
  • Außerdem wird im selben Server Listener-Port LP2 definiert und der Verbindungsfactory CF2 zugeordnet. Die Message-driven Beans MDB2A und MDB2B werden in derselben ejb-jar-Datei definiert und beide LP2 mit ergänzenden JMS-Selektoren zugeordnet. Der onMessage()-Anwendungscode von MDB2A und MDB2B führt Protokollierungsvorgänge aus, aber keine der MDBs führt selbst JMS-API-Aufrufe durch.
Lösung für Beispiel 1:
  • Bei Verbindungsfactory CF1 wird eine Verbindung für MDB1 gezählt. Die MDB1-Anwendung (die auch die Verbindungsfactory CF1 verwendet, um ihre weitergeleitete Nachricht zu senden) verwendet eine JMS-Verbindung, für die die Anzahl der Worker-Threads (12) gezählt und mit dem Wert '1' multipliziert wird. Die Gesamtanzahl der Verbindungen des Verbindungspools für Verbindungsfactory CF1 berechnet sich wie folgt: 13 = 12 + 1.
  • Für Verbindungsfactory CF2 wird je eine Verbindung für MDB2A und MDB2B gezählt. Es gibt keine Anwendungen, die CF2 verwenden (nur die Listener-Portinfrastruktur), daher wird die maximale Anzahl von Verbindungen für Verbindungsfactory CF2 auf den Wert '2' gesetzt.
  • Für alle zwei Verbindungsfactorys wird der Wert für die maximale Anzahl von Verbindungen auf '12' gesetzt.
Szenario für Beispiel 2:
  • Jeder Servant hat 12 Worker-Threads. In diesem Beispiel wird nur eine einzige Verbindungsfactory verwendet, CF1.
  • Jeder der zwei Listener-Ports LP1 und LP2 wird Verbindungsfactory CF1 zugeordnet. Die Message-driven Beans MDB1, MDB2 und MDB3 gehören zu drei eindeutigen EAR-Dateien von Anwendungen. MDB1 wird LP1 zugeordnet, aber MDB2 und MDB3 werden beide LP2 zugeordnet.
Lösung für Beispiel 2:
  • Bis zu diesem Punkt wird ein Bedarf an drei Verbindungen für Verbindungsfactory CF1 errechnet. Es gibt jedoch auch eine Servletkomponente, die Nachrichten in eine Warteschlange stellt, und auch sie verwendet die Verbindungsfactory CF1. Für Verbindungsfactory CF1 berechnet sich der Wert für die maximale Anzahl von Verbindung wie folgt: 15 = 3 + 12.

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cprf_tunezmdb_cf
Dateiname:cprf_tunezmdb_cf.html