Tipps zur Fehlerbehebung bei WS-ReliableMessaging

Tipps zur Behebung von Fehlern in der WS-ReliableMessaging-Konfiguration.

Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log, trace.log und activity.log auf verteilten oder IBM® i-Systemen. Sie können HPEL auch in Verbindung mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen.

Verwenden Sie für die Bestimmung und Behebung von Fehlern bei WS-ReliableMessaging Trace- und Protokollfunktionen von WebSphere Application Server. Wenn Sie Eclipse-basierte Tools verwenden, können Sie auch den TCP/IP-Monitor in Eclipse verwenden, um die Nachrichten anzuzeigen, die zwischen Ihren Clientanwendungen und Web-Services mit aktiviertem Reliable Messaging übertragen werden.

Wenn Sie die Traceerstellung für WS-ReliableMessaging aktivieren möchten, setzen Sie die Tracezeichenfolge für den Anwendungsserver wie folgt:
  • Für die verwalteten Servicequalitäten:
    org.apache.sandesha2*=all=enabled:com.ibm.ws.websvcs.rm*=all=enabled:org.apache.axis2*=all=enabled:com.ibm.ws.sib.wsrm*=all=enabled
  • Für die nicht verwaltete, nicht persistente Servicequalität:
    org.apache.sandesha2*=all=enabled:com.ibm.ws.websvcs.rm*=all=enabled:org.apache.axis2*=all=enabled
Wenn ein Fehler auftritt, den Sie für einen WS-ReliableMessaging-Fehler halten, können Sie in der Administrationskonsole von WebSphere Application Server und in der Datei SystemOut.log des Anwendungsservers prüfen, ob Fehlernachrichten vorhanden sind. Sie können auch den Debug-Trace des Anwendungsservers aktivieren, um einen ausführlichen Ausnahmespeicherauszug zu erhalten.

Eine Liste der wichtigsten bekannten Einschränkungen für die Verwendung von WS-ReliableMessaging finden Sie im Artikel Bekannte Einschränkungen von WS-ReliableMessaging.

Systemnachrichten von WebSphere Application Server werden von vielen Quellen, einschließlich Komponenten und Anwendungen des Anwendungsservers, protokolliert. Nachrichten, die von Komponenten des Anwendungsservers sowie zugeordneten IBM Produkten protokolliert werden, beginnen mit einer eindeutigen Nachrichten-ID, die die Komponente oder Anwendung anzeigt, welche die Nachricht ausgegeben hat. Das Präfix für die Komponente WS-ReliableMessaging ist CWSKA.

Der Artikel Referenz zur Fehlerbehebung: Nachrichten enthält Informationen zu allen Nachrichten von WebSphere Application Server, die nach Nachrichtenpräfix indexiert sind. Zu jeder Nachricht finden Sie eine Beschreibung und die empfohlenen Maßnahmen zur Behebung des Fehlers.

Die folgenden Tipps unterstützen Sie bei der Behebung häufig auftretender Probleme:

Aufgrund der erneuten Zuordnung der Nachrichtenfolgen sehen Sie möglicherweise mehr Nachrichtenfolgen als erwartet

Wenn Sie den Laufzeitstatus eingehender oder abgehender Nachrichtenfolgen überprüfen, sehen Sie möglicherweise aufgrund der erneuten Zuordnung mehr Nachrichtenfolgen als erwartet.

Wenn eine Nachrichtenfolge erneut zugeordnet wird, ist sowohl die ursprünglichen als auch die neuen Nachrichtenfolge sichtbar. Ignorieren Sie die doppelten Einträge.

[AIX Solaris HP-UX Linux Windows][IBM i]

Wenn Reliable Messaging in einem Cluster ausgeführt wird und Sie den Laufzeitstatus eingehender oder abgehender Nachrichtenfolgen untersuchen, werden für jede Nachrichtenfolge mehrere Einträge angezeigt

Dies ist darauf zurückzuführen, dass die Informationen zu den Nachrichtenfolgen in der Laufzeitanzeige einmal für jedes Cluster-Member ermittelt und angezeigt werden, obwohl das Reliable Messaging nur an eine einzige Messaging-Engine in einem Cluster gebunden ist. Ignorieren Sie die doppelten Einträge. Die geringfügigen Unterschiede in den Statistiken, die für jeden doppelten Eintrag angezeigt werden, sind auf die Einträge zurückzuführen, die nacheinander erstellt werden, während die Abfrage der Nachrichten fortgesetzt wird.

[z/OS]

Wenn Sie den Laufzeitstatus eingehender oder abgehender Nachrichtenfolgen untersuchen, können für jede Nachrichtenfolge mehrere Einträge angezeigt werden

Dies ist darauf zurückzuführen, dass die Informationen zu den Nachrichtenfolgen in der Laufzeitanzeige einmal für jede Servantregion ermittelt und angezeigt werden, obwohl das Reliable Messaging nur an eine einzige Messaging-Engine gebunden ist. Ignorieren Sie die doppelten Einträge. Die geringfügigen Unterschiede in den Statistiken, die für jeden doppelten Eintrag angezeigt werden, sind auf die Einträge zurückzuführen, die nacheinander erstellt werden, während die Abfrage der Nachrichten fortgesetzt wird.

Beim Migrieren persistenter WS-ReliableMessaging-Nachrichten von Version 6.1.0.9 oder 6.1.0.11 treten Laufzeitfehler auf

Wenn Sie eine Migration von WebSphere Application Server Version 6.1 durchführen, Feature Pack for Web Services Version 6.1.0.9 oder 6.1.0.11 verwenden und Ihre Konfiguration WS-ReliableMessaging (konfiguriert für verwaltete persistente Servicequalität) umfasst, müssen Sie vor der Migration alle persistenten Nachrichten entfernen.

Jede Nachricht wird als Teil einer Nachrichtenfolge, die gegenwärtig verarbeitet wird, persistent gespeichert. Führen Sie zum Löschen aller persistenten Nachrichten die folgenden Schritte in der Administrationskonsole aus:
  1. Navigieren Sie zur Laufzeitanzeige Eingehende Nachrichtenfolgen Ihrer Anwendung für Reliable Messaging.
  2. Wählen Sie alle eingehenden Nachrichtenfolgen aus, und klicken Sie dann auf Nachrichtenfolge und Nachrichten löschen, um die Nachrichtenfolgen zu löschen.
  3. Navigieren Sie zur Laufzeitanzeige Abgehende Nachrichtenfolgen, und wiederholen Sie die vorherigen Schritte für die abgehenden Nachrichtenfolgen.

Beim Start eines Anwendungsservers wird eine für Reliable Messaging verwendete Messaging-Engine als nicht verfügbar gemeldet

Wenn Sie Reliable Messaging mit einer verwalteten Servicequalität nutzen, wird beim Start des Anwendungsservers möglicherweise die folgende Ausnahmebedingungsnachricht angezeigt:

CWSIT0019E: Es ist keine
Messaging-Engine im Bus IhrBus vorhanden, die den angegebenen Verbindungseigenschaften entspricht. 

In einer Network-Deployment-Umgebung kann dieser Fall eintreten, weil die Messaging-Engine sich in einem Anwendungsserver oder einem Cluster-Member befindet, der bzw. das nach dem Server gestartet wurde, auf dem die Reliable Messaging-Anwendung installiert ist. In diesem Fall müssen Sie lediglich warten, denn beim Reliable Messaging wird so lange versucht, eine Verbindung herzustellen, bis die Messaging-Engine verfügbar ist.

Wenn Sie vermuten, dass ein anderes Problem vorliegt, dass z. B. die Bindungen falsch sind oder der Server, auf dem die Messaging-Engine installiert ist, nicht gestartet wird, führen Sie die folgenden Prüfungen durch:
  • Vergewissern Sie sich, dass die angegebene Messaging-Engine und der Service Integration Bus vorhanden sind.
  • Überprüfen Sie das Systemausgabeprotokoll, um sich zu vergewissern, dass der Server, auf dem die Messaging-Engine installiert ist, gestartet wurde.

Eine Clientanwendung kann einen Web-Service nicht aufrufen, der für Reliable Messaging aktiviert ist.

Wenn Ihre Clientanwendung einen Web-Service, der für Reliable Messaging aktiviert ist, nicht aufrufen kann, können Sie mit dem TCP-IP-Monitor die Nachrichten anzeigen, die zwischen dem Client und dem Service übertragen werden. Außerdem sollten Sie Folgendes sicherstellen:

Es wurde keine Nachrichtenfolge erstellt und WS-ReliableMessaging kann die Übertragung der Nachrichten nicht gewährleisten

Wenn eine Nachrichtenfolge erstellt wurde, sorgt WS-ReliableMessaging für die erneute Übertragung von Nachrichten an einen Service. Wenn die Nachrichtenfolge jedoch nicht erstellt wurde, werden die Nachrichten nicht an den Service übertragen, und es erscheint eine Nachricht wie die folgende:

org.apache.axis2.AxisFault: Die Anforderung zum Erstellen der Folge wurde vom RM-Ziel zurückgewiesen. 

Die ursprüngliche createSequence-Nachricht wurde zurückgewiesen. Dies wird zurückgemeldet und bewirkt das Scheitern des Clients. Weitere Informationen zu CreateSequence und CreateSequenceRefused finden Sie im Artikel WS-ReliableMessaging: Unterstützte Spezifikationen und Standards.

Möglicherweise wird eine weitere Nachricht angezeigt, in der erläutert wird, warum die Anforderung zurückgewiesen wurde. Beispiel:

Caused by: javax.xml.ws.soap.SOAPFaultException: com.ibm.ws.sib.wsrm.exceptions.WSRMRuntimeException: 
CWSJZ0202I: Für den Bus myBus ist keine Verbindung zur Messaging-Engine verfügbar.
.
Es liegt ein Problem in der Reliable Messaging-Konfiguration vor. Führen Sie die folgenden Prüfungen durch:
  • Prüfen Sie, ob die Richtliniensätze ordnungsgemäß angewendet wurden. Vergewissern Sie sich insbesondere, dass das Reliable Messaging für das Ziel ordnungsgemäß aktiviert wurde.
  • Suchen Sie in den Protokollen nach serverseitigen Problemen.
  • Prüfen Sie für die verwaltete Servicequalität, ob die zugehörige Messaging-Engine verfügbar ist.

Es wurde eine Nachrichtenfolge erstellt, die aber nicht verwendbar ist, und WS-ReliableMessaging kann die Übertragung der Nachrichten nicht gewährleisten

Wenn eine Ausnahme wie die folgende angezeigt wird, wurde die Nachrichtenfolge zwar erstellt, aber sie kann nicht verwendet werden:

javax.xml.ws.WebServiceException: org.apache.axis2.AxisFault: Der Wert von wsrm:Identifier ist keine bekannte Folgenkennung
.

Gewöhnlich ist das Problem darauf zurückzuführen, dass sie in einer Clusterumgebung arbeiten, aber Ihre serverseitige Richtlinie die nicht verwaltete, nicht persistente Servicequalität spezifiziert. Beispiel: Der Standardrichtliniensatz WS-I RSP spezifiziert die nicht verwaltete, nicht persistente Servicequalität. Wenn Sie zuverlässiges asynchrones Messaging in einer Clusterumgebung verwenden möchten, müssen Sie eine verwaltete Servicequalität verwenden, damit die Cluster-Member den Status des Reliable Messaging korrelieren können. Dazu können Sie entweder den definierten WS-I-RSP-ND-Standardrichtliniensatz verwenden, oder Ihren angepassten Richtliniensatz so ändern, dass die WS-ReliableMessaging-Richtlinie eine verwaltete Servicequalität und eine zugeordnete Bindungen zu einem Service Integration Bus und zu einer Messaging-Engine angibt. Weitere Informationen hierzu finden Sie in den Artikeln WS-ReliableMessaging-Richtliniensatz über die Administrationskonsole konfigurieren und Mit der Administrationskonsole einen WS-ReliableMessaging-Richtliniensatz einer Web-Service-Anwendung zuordnen und an diese binden.

Der verwaltete Speicher für Reliable Messaging wird nicht initialisiert, weil die Richtliniensatzbindung unvollständig oder ungültig ist

Wenn Ihr Richtliniensatz eine verwaltete Servicequalität spezifiziert, Sie aber keine Bindung zu einer Messaging-Engine für die Unterstützung dieser Servicequalität angegeben haben, wird die folgende Ausnahme angezeigt:

CWSKA0102E: Der verwaltete WS-ReliableMessaging-Speichermanager konnte nicht initialisiert werden,
weil die Richtliniensatzbindung unvollständig oder ungültig ist. 
.

Möglicherweise haben Sie Ihrer Anwendung einen verwalteten Richtliniensatz zugeordnet und die Standardbindungen verwendet (die die verwalteten Servicequalitäten nicht unterstützen). Sie müssen eine neue Bindung für Ihre Anwendung erstellen, die einen Service Integration Bus und eine Messaging-Engine für die Unterstützung der verwalteten Servicequalitäten spezifiziert. Diesbezügliche Anweisungen finden Sie im Artikel Mit der Administrationskonsole einen WS-ReliableMessaging-Richtliniensatz einer Web-Service-Anwendung zuordnen und an diese binden.

Reliable Messaging ist unterbrochen, weil ein Server nicht verfügbar ist

Clustering bietet einen maximalen Schutz bei Nichtverfügbarkeit von Servern. Clustering stellt Serviceendpunkte mit hoher Verfügbarkeit bereit und gewährleistet (über den Service Integration Bus) eine hohe Verfügbarkeit des Reliable Messaging.

Weitere Informationen zum Konfigurieren der hohen Verfügbarkeit für Web-Services und Messaging-Engines finden Sie in den Artikeln Gleichmäßige Lastverteilung und Einem Cluster eine Messaging-Engine hinzufügen.

Bei der Ausführung mehrerer Reliable Messaging-Clientanwendungen in einem Cluster werden Fehler aufgrund von Überschreitungen des Socket-Zeitlimits empfangen

Wenn viele Anwendungen dieselbe Messaging-Engine verwenden, kann dies die Leistung beeinträchtigen und in manchen Fällen zu Fehlern aufgrund von Überschreitungen des Zeitlimits führen.

Weitere Informationen zum Konfigurieren der hohen Verfügbarkeit für Web-Services und Messaging-Engines finden Sie in den Artikeln Gleichmäßige Lastverteilung und Einem Cluster eine Messaging-Engine hinzufügen.

Eine Nachricht bei Ausfall eines Servers nicht wiederhergestellt

Wenn die Reliable Messaging-Schicht eine Anforderungsnachricht empfängt, sendet sie eine Bestätigung und stellt die Nachricht dann dem Zielservice zu. Es besteht ein geringfügiges Risiko, dass der Server, der das Reliable Messaging bereitstellt, nach der Bestätigung und vor der Zustellung der Anforderungsnachricht ausgefallen ist. In diesem Fall wird die Nachricht nur dann wiederhergestellt, wenn Sie das Zustellverfahren mit Einhaltung der Nachrichtenreihenfolge und eine verwaltete persistente Servicequalität verwenden. Wenn Sie das Zustellverfahren mit Einhaltung der Nachrichtenreihenfolge festlegen möchten, setzen Sie die WS-ReliableMessaging-Richtlinienoption auf "Nachrichten in der gesendeten Reihenfolge zustellen". Diesbezügliche Anweisungen finden Sie im Artikel Richtlinie für WS-ReliableMessaging konfigurieren.

Anmerkung: Bei dem Zustellverfahren mit Einhaltung der Nachrichtenreihenfolge kommt es zu Leistungseinbußen, weil die Nachrichten in einer Warteschlange gehalten werden, bis sie zugestellt werden können. Wenn jedoch die höchste Zuverlässigkeitsstufe gefordert ist, wird empfohlen, stets das Zustellverfahren mit Einhaltung der Nachrichtenreihenfolge in Kombination mit der verwalteten, persistenten Servicequalität zu verwenden.

Eine Ausnahmebedingungsnachricht zeigt an, dass das Sicherheitskontexttoken nicht gültig ist

Bei Verwendung des Reliable Messaging mit einem persistenten WS-I-RSP-Profil und WS-SecureConversation wird eine Ausnahmebedingungsnachricht abgesetzt, die besagt, dass das Sicherheitskontexttoken nicht gültig ist.

Wenn Sie einen persistenten WS-I-RSP-Richtliniensatz verwenden, der WS-SecureConversation enthält, und das Sicherheitskontexttoken für das Scoping beim Neustart des Servers abgelaufen ist, kann WS-ReliableMessaging seine Nachrichten nicht erneut senden, und es werden Systemnachrichten in die Protokolldatei geschrieben, die besagen, dass die zuverlässige Nachrichtenfolge nicht mit dem richtigen Sicherheitstoken gesichert wurde. Beispiel:
CWWSS7215E: Es konnte kein gültiges Sicherheitskontexttoken aus dem Cache abgerufen werden.

Führen Sie die folgende Task aus, um sicherzustellen, dass der Sicherheitskontext für das Scoping nicht verfällt, bevor WS-ReliableMessaging seine Nachrichten wiederherstellen und erneut senden kann: WS-SecureConversation für die Zusammenarbeit mit WS-ReliableMessaging konfigurieren.

[z/OS]

Eine Servant-Region wird aufgrund einer Zeitlimitüberschreitung abnormal beendet, wenn Sie eine verwaltete Servicequalität verwenden.

Eine abnormale Beendigung aufgrund einer Zeitlimitüberschreitung kann darauf zurückzuführen sein, dass der Wert für die angepasste Eigenschaft "sib.wsrm.tokenLockTimeout" zu hoch ist. Diese Eigenschaft wird in der Messaging-Engine gesetzt, die in der WS-ReliableMessaging-Richtlinienbindung angegeben ist. Der Wert sollte kleiner sein als die Zeit, die die Steuerregion wartet, bevor sie eine inaktive Servant-Region beendet. Weitere Informationen zu dieser Eigenschaft finden Sie im Artikel Angepasste Eigenschaften der Serviceintegration.


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=rwbs_wsrm_prob0
Dateiname:rwbs_wsrm_prob0.html