WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

Verbindungsmanagement

TCP/IP-Verbindungen werden vom Clientverbindungsmanager angefordert und vom Serververbindungsmanager angenommen.

Der Ausführungsgruppenprozess umfasst den Verbindungsmanager, der die Verbindungen herstellt. Nur eine einzige Ausführungsgruppe kann Serverknoten enthalten, die einen bestimmten Port zu einer bestimmten Zeit verwenden; die Implementierung in einer zweiten Ausführungsgruppe führt zu einem Implementierungsfehler. Clientknoten können in verschiedenen Ausführungsgruppen implementiert werden, wobei aber jede Ausführungsgruppe über einen eigenen Verbindungspool und damit über eine eigene minimale und maximale Anzahl von Verbindungen verfügt.

TCP/IP-Verbindungen werden nicht direkt von den TCP/IP-Knoten erstellt oder verwaltet, sondern aus dem internen Pool des Verbindungsmanagers übernommen. Beispielsweise nutzen zwei Sendeknoten, die dieselben Verbindungsdetails verwenden, beide denselben Verbindungsmanager. Die TCP/IP-Knoten können die zu verwendenden Verbindungsdetails durch Angabe eines der folgenden Werte definieren:

Wenn ein Hostname und Port angegeben werden, verwendet der Knoten diese Werte bei der Anforderung von Verbindungen. Wird ein konfigurierbarer Service angegeben, ruft der Knoten die Werte für den Port und den Hostnamen aus den Werten ab, die im konfigurierbaren Service definiert sind. Vom Verbindungsmanager werden zusätzlich zum Hostnamen und Port weitere konfigurierbare Parameter unterstützt. Alle diese Werte können Sie bei Verwendung eines konfigurierbaren Service definieren. Wenn der Hostname und Port auf dem Knoten angegeben sind, ruft der Verbindungsmanager die übrigen erforderlichen Werte vom standardmäßigen konfigurierbaren Service ab. Wenn jedoch ein konfigurierbarer Service definiert ist, der den Hostnamen und die Portnummer verwendet, werden die Werte aus diesem konfigurierbaren Service verwendet.

Der Verbindungsmanager wird erstellt, sobald der erste Knoten, der Verbindungen bei ihm anfordert, implementiert wird. Der Verbindungsmanager wird gelöscht, wenn der letzte verbleibende Knoten, der den Manager verwendet, aus der Ausführungsgruppe entfernt wurde (der Verbindungsmanager also von keinem implementierbaren Knoten mehr verwendet wird). Dieser Prozess kann beispielsweise bei einer erneuten Implementierung vorhandener Nachrichtenflüsse eintreten, da bei der erneuten Implementierung alle vorhandenen Knoten gelöscht werden, bevor sie erneut erstellt werden.

Der Verbindungsmanager wendet die an einem konfigurierbaren TCPIPClient-Service vorgenommenen Änderungen an, ohne dass ein Neustart von Ausführungsgruppen erforderlich ist. Der Verbindungsmanager wendet die Änderungen des konfigurierbaren TCP/IP-Service auf alle Nachrichtenflüsse an, die den Service nutzen. Nach der Anwendung der Änderungen des konfigurierbaren TCP/IP-Service müssen die TCP/IP-Verbindungsmanager neu gestartet werden, so dass davon ausgegangen werden kann, dass alle Nachrichtenflüsse, die zur Angabe ihrer TCP/IP-Parameter konfigurierbare Services verwenden, die neuen TCP/IP-Verbindungen kennen.

Der Verbindungsmanager aktualisiert die betroffenen Knoten erst, nachdem jeder betroffene Nachrichtenfluss die aktuelle Nachricht verarbeitet hat. Sobald ein betroffener Nachrichtenfluss die aktuelle Nachricht verarbeitet hat, wird er gesperrt, bis die Aktualisierungen für alle betroffenen Nachrichtenflüsse beendet sind. Dieser Prozess soll sicherstellen, dass alle Knoten, die in derselben Ausführungsgruppe enthalten sind, denselben Wert für den geänderten konfigurierbaren Service verwenden. Aus diesem Grund kann zwischen der Anwendung der Aktualisierung des konfigurierbaren Service und der Aktualisierung der vom Nachrichtenfluss verwendeten Eigenschaften eine Verzögerung von einigen Sekunden auftreten.

Serververbindungen

Sobald der Serververbindungsmanager gestartet ist, ist er für Serververbindungen empfangsbereit. Er nimmt so lange Verbindungen an, bis die maximale Anzahl Verbindungen (wie im konfigurierbaren Service angegeben) erreicht ist. Alle Versuche, weitere Verbindungen herzustellen, werden zurückgewiesen. TCP/IP-Server erstellen keine Verbindungen, sondern sie nehmen lediglich Verbindungsanforderungen von anderen Anwendungen an. Deshalb kann die Herstellung von Verbindungen innerhalb eines Nachrichtenflusses nicht erzwungen werden.

Clientverbindungen

Der Clientverbindungsmanager wird gestartet und stellt dann so lange Clientverbindungen her, bis die minimale Anzahl Verbindungen (wie im konfigurierbaren Service festgelegt) erreicht ist. Die minimale Anzahl Verbindungen ist standardmäßig auf null gesetzt, d. h., es werden keine Verbindungen hergestellt. Sobald die Anzahl Verbindungen unter den Mindestwert fällt, beginnt der Verbindungsmanager damit, weitere Clientverbindungen zu erstellen. Die Sendeknoten und Receive-Knoten des Clients leiten die Erstellung neuer Clientverbindungen ein, sobald keine Verbindungen mehr verfügbar sind, es sei denn, die maximale Anzahl (wie im konfigurierbaren Service festgelegt) wurde erreicht.

Verbindungen reservieren und freigeben

Jede Verbindung besitzt einen Eingabedatenstrom und einen Ausgabedatenstrom, für die der Verbindungsmanager zwei Hauptzustände kennt: verfügbar und reserviert.

Wenn ein Knoten eine Verbindung zum Empfangen oder Senden anfordert, ohne die ID einer bestimmten Verbindung anzugeben, wird ihm eine beliebige verfügbare Verbindung für den gewünschten Datenstrom zugewiesen. Wenn keine Verbindungen verfügbar sind und der Knoten ein Clientknoten ist, wird eine neue Verbindung erstellt, aber nur, wenn die maximale Anzahl Verbindungen noch nicht erreicht wurde. Eine Verbindung mit dem Zustand 'verfügbar' kann immer nur von einem einzigen Knoten verwendet werden. Aber sobald ein Knoten die Verwendung beendet, kann jeder andere Knoten (aus jedem beliebigen Nachrichtenfluss oder Thread) auf die Verbindung zugreifen.

Sie können den Zugriff auf den Datenstrom einer Verbindung einschränken, indem Sie die Verbindung reservieren. Hat eine Verbindung den Zustand 'reserviert', kann kein anderer Knoten auf den Datenstrom zugreifen, ohne die ID der Verbindung anzugeben. Beispielsweise kann ein Empfangsknoten eine verfügbare Verbindung anfordern und den Datenstrom nach dem Lesen der Daten in den Zustand 'reserviert' versetzen. Solange sich der Datenstrom in diesem Zustand befindet, kann kein Empfangsknoten (einschließlich des Knotens, der den Datenstrom in den Zustand 'reserviert' versetzt hat) darauf zugreifen, weil Empfangsknoten nur auf verfügbare Datenströme zugreifen können. Die einzigen Knoten, die auf den Datenstrom zugreifen können, müssen die Verbindungs-ID besitzen, die in die abgehende lokale Umgebung geschrieben wird, wenn die Daten im Nachrichtenfluss abwärts übergeben werden. Receive-Empfangsknoten können folglich in derselben Verbindung mehr Daten lesen, dies gilt allerdings nur, wenn der Receive-Empfangsknoten für die Verwendung der ID aus der lokalen Umgebung des Empfangsknotens konfiguriert ist.

Bei der Reservierung einer Verbindung geht das Eigentumsrecht an der Verbindung an einen aktuellen Verarbeitungs-Thread über. Diese Verarbeitung kann, falls erforderlich, separate Nachrichtenflüsse umfassen.

Der Reservierungsmechanismus bietet folgende Optionen:
  • Unverändert lassen
  • Reservieren
  • Freigeben
  • Reservieren und am Ende des Nachrichtenflusses freigeben

Für alle Knoten bleibt der Datenstrom standardmäßig verfügbar (keine Reservierung). Diese Standardeinstellung kann für viele Verarbeitungsarten unverändert beibehalten werden, beispielsweise wenn Daten aus einem Eingabedatenstrom in eine Datei verschoben werden. Hauptzweck einer Datenstromreservierung ist es, dass mehrere Knoten miteinander verbunden werden, um eine komplexe Verarbeitung eines Datenstroms in einer festgelegten, gesteuerten, synchronen Folge zu ermöglichen.

Über die Option Reservieren und am Ende des Nachrichtenflusses freigeben kann eine Verbindung reserviert werden, wobei sichergestellt ist, dass der Datenstrom der Verbindung freigegeben wird, sobald eine Iteration des Nachrichtenflusses die Verarbeitung (einschließlich möglicherweise auftretender Fehlerbedingungen) beendet hat.

Wenn die Verarbeitung auf mehrere Nachrichtenflüsse verteilt werden muss (z. B. für eine asynchrone Anforderung und Antwort), muss ein Datenstrom reserviert werden, der nicht am Ende des Nachrichtenflusses freigegeben wird. Im Folgenden ein Beispiel:

Informationen zu Beispielen können nur bei Verwendung des in das WebSphere Message Broker Toolkit integrierten bzw. online verfügbaren Information Center angezeigt werden. Muster können nur ausgeführt werden, wenn das im WebSphere Message Broker Toolkit integrierte Information Center verwendet wird.

Ein Nachteil bei der Reservierung eines Datenstroms zwischen Nachrichtenflüssen ist, dass ein Datenstrom möglicherweise niemals freigegeben wird. Um dieses Problem zu vermeiden, muss eine Ablaufzeit für die Verbindung festgelegt werden, sodass sie nach Ablauf eines angegebenen Inaktivitätszeitraums geschlossen wird.

Ein weiterer Vorteil der Reservierung eines Eingabedatenstroms besteht darin, dass die Verbindung erst geschlossen werden kann, nachdem sie freigegeben wurde oder abgelaufen ist (auch dann, wenn eine Endanwendung ihr Ende der Verbindung schließt). Dies ist hilfreich, wenn das Ende des Datenstroms verwendet wird, um Nachrichten im Datenstrom zu begrenzen.

Dateideskriptoren

Wenn Sie Ihre WebSphere Message Broker-Anwendung auf einem SPARC-System unter Sun Solaris 10 einsetzen, müssen Sie möglicherweise die Anzahl der Dateideskriptoren erhöhen. Mit dem folgenden Fehler im Systemprotokoll (syslog) wird angegeben, dass zusätzliche Dateideskriptoren erforderlich sind:
 Fehler beim Aufbau einer Clientverbindung mit Hostname '' und Port ''. Ursache: 'Ungültiges Argument'
Sie können auch versuchen, den Fehler mit den beiden folgenden Verfahren zu beheben:
  • Ändern Sie die Umgebungsvariable MQSIJVERBOSE z. B.:
    export MQSIJVERBOSE=-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider
  • Ändern Sie den Grenzwert für die maximale Anzahl an Dateikennungen und geben Sie Wert anstelle von RLIM64_INFINITY an.
Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:20:32


KonzeptthemaKonzeptthema | Version 8.0.0.5 | ac67380_