Angepasste Eigenschaften des TCP-Transportkanals

Wenn Sie einen TCP-Transportkanal verwenden, können Sie angepasste Eigenschaften für TCP-Transportkanäle verwenden, um interne Eigenschaften für TCP-Transportkanäle zu konfigurieren.

Führen Sie die folgenden Aktionen aus, um eine angepasste Eigenschaft für einen TCP-Transportkanal hinzuzufügen.
  1. Klicken Sie in der Administrationskonsole auf Server > Servertypen und verwenden Sie anschließend einen der folgenden Navigationspfade:
    • Klicken Sie in der Administrationskonsole auf Anwendungsserver > Servername und wählen Sie dann je nach Typ der zu erstellenden Kette eine der folgenden Optionen aus:
      • Klicken Sie unter Einstellungen für SIP-Container auf Transportketten für SIP-Container.
      • Klicken Sie unter Einstellungen für Web-Container auf Transportketten für Web-Container.
      • [z/OS]Klicken Sie unter Containerservices auf ORB-Service > Transportketten für ORB-Service.
      • Klicken Sie unter Server-Messaging auf Eingehende Transporte für die Messaging-Engine oder Eingehende Transporte für IBM MQ-Link.
    • Klicken Sie auf Proxy-Server und dann unter HTTP-Einstellungen für Proxy-Server auf Transport für Proxy-Server und wählen Sie HTTPS_PROXY_CHAIN oder HTTP_PROXY_CHAIN aus. Klicken Sie anschließend auf HTTP-Proxy-Kanal für eingehende Anforderungen.
  2. Wählen Sie die Transportkette aus, die den TCP-Kanal enthält, für den Sie die angepasste Eigenschaft festlegen möchten.
  3. Wählen Sie den TCP-Kanal für eingehende Anforderungen aus.
  4. Klicken Sie auf Angepasste Eigenschaften > Neu, und geben Sie anschließend unter "Allgemeine Eigenschaften" im Feld Name den Namen der angepassten Eigenschaft und im Feld Wert den Wert für diese Eigenschaft ein. Im Feld Beschreibung können Sie eine Beschreibung für diese Eigenschaft eingeben.
  5. Klicken Sie auf Anwenden oder OK.
  6. Klicken Sie auf Speichern, um die Konfigurationsänderungen zu speichern.
  7. Starten Sie den Server erneut.
Mit dem Produkt werden die folgenden angepassten Eigenschaften für TCP-Transportkanäle bereitgestellt. Diese Eigenschaften werden auf der Seite mit den Einstellungen für einen TCP-Transportkanal nicht angezeigt.

listenBacklog

Mit der Eigenschaft "listenBacklog" geben Sie die maximale Anzahl ausstehender Verbindungsanforderungen an, die das Betriebssystem puffert, während es darauf wartet, dass der Anwendungsserver die Verbindungen akzeptiert. Wenn ein Client versucht, eine Verbindung herzustellen, und dieser Puffer erschöpft ist, wird die Verbindungsanforderung zurückgewiesen. Der Wert dieser Eigenschaft ist für jeden Transport einzeln festzulegen.

Wenn Sie die Anzahl gleichzeitig bestehender Verbindungen steuern müssen, verwenden Sie das Feld Maximale Anzahl geöffneter Verbindungen auf der Seite mit den Einstellungen für TCP-Transportkanäle in der Administrationskonsole.

Information Wert
Datentyp Integer
Standardwert 511
[z/OS]Anmerkung: Der Wert, den Sie für listenBacklog verwenden, kann durch Angabe der Anweisung SOMAXCONN im TCP/IP-Profil begrenzt werden. Wenn Sie für listenBacklog einen Wert verwenden, der größer ist als der SOMAXCONN-Wert, wird der Wert für listenBacklog nicht verwendet. Stattdessen wird der Wert für SOMAXCONN verwendet.

Wichtiger Hinweis: Wird listenBacklog für die Kanaltypen HTTP, HTTP SSL, IIOP und IIOP SSL nicht festgelegt, wird der Wert für listenBacklog aus den veralteten Umgebungswerten verwendet: protocol_http_backlog, protocol_https_backlog, protocol_iiop_backlog und protocol_iiop_backlog_ssl. Wenn kein Wert für die zugehörige veraltete Umgebungsvariable angegeben ist, wird der Standardwert 10 verwendet.

Für andere Kanaltypen als HTTP, HTTP SSL, IIOP und IIOP SSL wird für listenBacklog der Standardwert 511 verwendet.

[z/OS]

zaioFreeInitialBuffers

Verwenden Sie die angepasste Eigenschaft zaioFreeInitialBuffers, um anzuzeigen, dass der TCP-Kanal die anfänglichen Lesepuffer, die in neuen Verbindungen verwendet werden, freigeben soll, sobald diese Puffer für die Verbindung nicht mehr benötigt werden. Standardmäßig wird dieser anfängliche Lesepuffer für jede Verbindung zwischengespeichert. Wenn eine Verbindung geschlossen wird, wird der Lesepuffer wiederverwendet, um eine Hauptspeicherzuordnung zu vermeiden. Dieser Prozess funktioniert einwandfrei für nicht persistente Verbindungen, bei denen pro Verbindung nur eine Anforderung bearbeitet wird. Bei Verbindungen mit hoher Persistenz kann der Puffer jedoch sehr lange gehalten werden, selbst wenn er nicht mehr verwendet wird. Diese Situation kann bei Arbeitslasten, die eine hohe Anzahl verbundener Clients erfordern, zu einer Knappheit beim LE-Heapspeicher (Language Environment) führen. Wenn sich Ihre Arbeitslast nicht hauptsächlich aus nicht persistenten Verbindungen zusammensetzt, sollten Sie diese angepasste Eigenschaft auf "true" setzen, um die Freigabe der anfänglichen Lesepuffer zu aktivieren.

Anmerkung: Wenn Sie diese Eigenschaft auf "true" setzen, müssen Sie den generischen JVM-Argumenten, die für den Anwendungsserver, der diesen TCP-Kanal verwendet, das folgende Argument hinzufügen:
-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=
    com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl
Information Wert
Datentyp String
Standardwert false

soReuseAddr

Verwenden Sie die angepasste Eigenschaft "soReuseAddr", um das Bindungsverhalten zu steuern. Wenn WebSphere Application Server erneut gestartet wird und die eingehenden TCP-Kanäle Probleme beim Binden des Empfangssockets haben, werden Fehler in der Datei SystemOut ausgegeben, bis die Bindung erfolgreich ist oder die zulässige Anzahl an Bindungsversuchen erreicht ist. Mithilfe dieser angepassten Eigenschaft können wiederholte Fehlernachrichten während des Bindeprozesses vermieden werden.

Für Umgebungen mit eingehenden TCP-Kanalbindungen können Sie die wiederholten Fehlernachrichten vermeiden, indem Sie die Verarbeitung am eingehenden TCP-Kanal mit der angepassten Eigenschaft "SoReuseAddr" beeinflussen. Wenn Sie "SoReuseAddr" auf 1 setzen, wird der TCP-Kanal gezwungen, jeden Bindungsversuch mit aktivierter Wiederverwendungsoption am Socket zu wiederholen. Beim Neustart von WebSphere Application Server wird der erste Bindungsversuch trotz dieser Sockets im Status TIME_WAIT verarbeitet.
Anmerkung: Beim ersten Neustart nach dem Anwenden der Eigenschaft "soReuseAddr" wird die vorherige Instanz der Bindung verarbeitet (die mit "false" gebunden wurde). Es können zwei Neustarts erforderlich sein, bis die Wiederverwendung immer erfolgreich ist, wenn die Wiederverwendung aktiviert ist. Sie können auch warten, bis keine Sockets mehr im Status TIME_WAIT vorhanden sind, bevor ein Neustart durchgeführt wird.
Information Wert
Datentyp Integer
Standardwert 0

Symbol, das den Typ des Artikels anzeigt. Referenzartikel



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