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.

Fehlerbehebung bei JMS-Knoten

Sie können möglicher Probleme mit Knoten prüfen, die den JMS-Transport verwenden.

Verwenden Sie zuerst das Aktivitätenprotokoll zur Diagnose eines Problems, wenn in einem JMS-Nachrichtenfluss etwas Unerwartetes geschieht. Das Aktivitätenprotokoll enthält die jüngsten Aktivitäten in Ihren Nachrichtenflüssen und den zugeordneten externen Ressourcen und zeigt in einer Art Übersicht alle Probleme an, die bei Ihren JMS-Ressourcen auftreten. Im Aktivitätenprotokoll erhalten Sie auch Fehlerinformationen.

Wenn es sich in einem Fall bei der zugrunde liegenden Fehlerursache um eine JMS-Ausnahmebedingung handelt, die vom JMS-Provider ausgegeben wurde, finden Sie in der BIP-Ereignisnachricht des Brokers die Textnachricht der JMS-Ausnahmebedingung, die Sie bei der Fehlerdiagnose unterstützt.

Ungültig formatierte Nachrichten verwalten

Wenn eine Nachricht nicht vom JMS-Empfangsknoten verarbeitet werden kann oder als Teil einer XA-koordinierten Transaktion rückgängig gemacht wurde, wird die Nachricht auf das ursprüngliche Ziel zurückgesetzt. In diesem Fall wird die Nachricht dem Empfangsknoten erneut zugestellt.

Damit die Verarbeitung gültiger Nachrichten nicht durch ungültig formatierte Nachrichten unterbrochen wird, können die Knoteneigenschaften wie in der folgenden Tabelle konfiguriert werden.
Eigenschaft Beschreibung
Rücksetzziel Diese Eigenschaft gibt eine JMS-Zieladresse an, an die zurückgesetzte Nachrichten geleitet werden, wenn die vom JMS-Provider festgelegte JMS-Nachrichteneigenschaft JMSX_DeliveryCount den Rücksetzschwellenwert überschreitet.

Die JMS-Zieladresse muss auf das vom Knoten verwendete Nachrichtenmodell anwendbar sein; wenn ein Subskriptionsthema beispielsweise auf dem Knoten konfiguriert wurde, muss die JMS-Zieladresse ebenfalls ein Thema sein.

Rücksetzschwellenwert Diese Eigenschaft gibt den ganzzahligen Wert an, über den eine Nachricht gesteuert wird, die an das Rücksetzziel gesendet wird. Der Schwellenwert 3 gibt Folgendes an: Wenn der Empfangsknoten eine Nachricht empfängt, deren Wert der Eigenschaft JMSX_DeliveryCount 3 überschreitet, wird die Nachricht an das Rücksetzziel gesendet und aus dem Quellenziel entfernt. Weitere Informationen hierzu finden Sie unter Eigenschaft 'Rücksetzschwellenwert' konfigurieren.

Probleme bei Verwendung XA-koordinierter Transaktionen diagnostizieren

Dieses Problem gilt nicht für z/OS.

Zusätzlich zum Broker-Service-Trace wird ein weiteres Traceprotokoll zur Diagnose von Problemen bereitgestellt, die auftreten können, wenn ein Knoten, der den JMS-Transport nutzt, an einer XA-koordinierten Nachrichtenflusstransaktion teilnimmt. Das heißt, dass für mindestens einen JMS-Knoten im Nachrichtenfluss die Eigenschaft Transaktionsmodus auf Ja gesetzt ist und die Nachrichtenflusseigenschaft Koordinierte Transaktion auf Ja gesetzt ist.

Gehen Sie zur Erfassung des Traceprotokolls folgendermaßen vor:
  1. Definieren Sie eine Umgebungsvariable mit der Bezeichnung XAJMS_TRACEFILE, die für den WS-Manager des Brokers verfügbar ist.
  2. Legen Sie den Wert der Umgebungsvariable fest. Dieser Wert muss eine Zeichenfolge sein, die die Position und den Dateinamen des Traceprotokolls wiedergibt. Unter Windows könnte die Variable beispielsweise wie im folgenden Beispiel dargestellt konfiguriert werden:
    XAJMS_TRACEFILE = c:\JMSSwitchLog
  3. Nach dem Start des WS-Managers des Brokers werden Fehlerbehebungsmaßnahmen ausgeführt, um mögliche frühere Brokertransaktionen aufzulösen, die der JMS-Provider als unbestätigt betrachtet. Durch den WS-Managerprozess werden zu diesem Zeitpunkt zwei Traceprotokolle geschrieben. Die zwei Traceprotokolle lauten folgendermaßen:
    • XAJMS_TRACEFILE valuePID.txt; dabei ist PID die Prozess-ID für den Startvorgang des WS-Managers. Diese Datei wird durch die JMSSwitch-Bibliothek des Brokers erstellt; weitere Informationen dazu finden Sie unter JMS-Transaktionalität.

      Im vorherigen Beispiel wird eine Datei mit dem Namen JMSSwitchLog2596.txt erstellt, wobei '2596' die Prozess-ID für den Startvorgang des WS-Managers ist.

    • XAJMS_TRACEFILEXARecoveryTrace.txt; dieses Traceprotokoll wird durch die Brokerkomponente zur Wiederherstellung erstellt, die mit dem JMS-Provider verbunden ist.
  4. Nachdem der WS-Manager des Brokers wiederhergestellt wurde, wird der Broker gestartet und er erstellt eine Datei mit dem Namen XAJMS_TRACEFILE valuePID.txt; dabei ist PID die Prozess-ID für den Startvorgang des WS-Managers. Diese Datei wird durch die JMSSwitch-Bibliothek des Brokers erstellt; weitere Informationen dazu finden Sie unter JMS-Transaktionalität.

Diese Tracedateien müssen nicht zusätzlich formatiert werden.

Probleme mit verwalteten JNDI-Objekten

Problembeschreibung: Der JMS-Knoten kann die Ausgangskontextfactory oder ein verwaltetes JNDI-Objekt (z. B. die Verbindungsfactory oder JMS-Zieladresse) nicht abrufen, und es wird die Fehlernachricht BIP4640 ausgegeben.

Problembehebung
  1. Stellen Sie sicher, dass die JNDI-Bindungen korrekt erstellt wurden und an der angegebenen Position im Knoten erreicht werden können.
  2. Überprüfen Sie, ob die im Knoten angegebenen Werte für die Eigenschaften Verbindungsfactory-Name und Quellenwarteschlange oder Zielwarteschlange in den JNDI-Bindungen vorhanden sind.
  3. Stellen Sie sicher, dass das Schlüsselwort mit der Position der Bindungen übereinstimmt:
    • file:// wenn die verwalteten Objekte in einer .bindings-Datei erstellt wurden
    • ldap:// wenn sich die verwalteten Objekte in einem LDAP-Verzeichnis befinden
    • iiop:// wenn zum Zugriff auf die verwalteten Objekte der CORBA-Standard verwendet wird
  4. Geben Sie den .bindings-Dateinamen in den Knoteneigenschaften nicht an, wenn die Bindungen auf einer Datei basieren.
  5. Stellen Sie sicher, dass der Klassenname der Ausgangskontextfactory wie in der Dokumentation des JMS-Providers angegeben richtig festgelegt wurde.
  6. Stellen Sie sicher, dass der Klassenname der Ausgangskontextfactory keinen Dateipfad enthält.
  7. Stellen Sie sicher, dass eine in den Knoteneigenschaften angegebene JMS-Zieladresse (Thema oder Quellenwarteschlange bzw. Zielwarteschlange) in den verwalteten JNDI-Objekten vorhanden ist.
  8. Vergewissern Sie sich mithilfe des Befehls mqsichangeproperties, dass die JMS-Provider-Eigenschaft 'jarsURL' richtig festgelegt wurde. Überprüfen Sie den Befehl mit folgendem Befehl:
    mqsireportproperties MB8BROKER -c JMSProviders -o JMSProvider –r
Die JMS-Knoten versuchen weiterhin, die verwalteten JNDI-Objekte abzurufen. Berichtigen Sie mögliche Fehler, und stellen Sie die Bindungen erneut her. Der JMS-Knoten sollte die Änderungen automatisch erkennen und einen Startversuch unternehmen.
  • Wenn das Problem durch erneutes Erstellen der Bindungen behoben wird, erkennt der JMS-Knoten die Änderungen automatisch und versucht zu starten.
  • Wenn das Problem durch Aktualisieren der Knoteneigenschaften behoben wird, müssen Sie den Nachrichtenfluss erneut implementieren, bevor eine Verbindung hergestellt werden kann.
  • Wenn das Problem durch Aktualisieren der Eigenschaften des konfigurierbaren Service 'JMSProviders' behoben wird, müssen Sie die Ausführungsgruppe erneut starten, damit die Änderungen übernommen werden.

Problembeschreibung: Ein JMS-Knoten kann keine Verbindung zu einem JMS-Provider erstellen und es wird die Fehlernachricht BIP4648 ausgegeben.

Problembehebung:
  1. Stellen Sie sicher, dass der Server des JMS-Providers ausgeführt wird. Falls der Server offline ist, müssen Sie ihn starten.
  2. Stellen Sie sicher, dass der Server des JMS-Providers in der Brokerumgebung verfügbar ist.
  3. Stellen Sie sicher, dass sich die JAR-Java™-Dateien des JMS-Providers auf verteilten Systemen im gemeinsamen Klassenverzeichnis des Brokers befinden bzw. dass diese JAR-Dateien unter z/OS in der Variablen CLASSPATH des Brokers und native Bibliotheken in der Variablen LIBPATH des Brokers definiert wurden.
Die JMS-Knoten versuchen weiterhin, eine Verbindung mit dem JMS-Provider herzustellen. Nachdem Sie die Fehler behoben haben, sollte der JMS-Knoten die Änderungen automatisch erkennen und versuchen, eine Verbindung zum Provider herzustellen.

Problembeschreibung: Ein JMS-Knoten kann keine JMS-Zieladresse aufrufen und es wird die Fehlernachricht BIP4642 ausgegeben.

Problembehebung
  1. Überprüfen Sie die in der JMS-Ausnahmebedingungsnachricht beschriebene Fehlerursache, in der möglicherweise die BIP-Ereignisnachricht enthalten ist.
  2. Stellen Sie sicher, dass der in der relevanten Knoteneigenschaft definierte Name der JMS-Zieladresse (Thema, Quellenwarteschlange oder Zielwarteschlange) in den verwalteten JNDI-Objekten korrekt definiert wurde.
  3. Stellen Sie sicher, dass die zugrunde liegende Systemressource, die vom JMS-Provider für die JMS-Zieladresse verwendet wird, korrekt konfiguriert wurde.

Problembeschreibung: Nach einem Verbindungsfehler oder dem Neustart des JMS-Providers versucht ein JMS-Empfangsknoten nicht, erneut eine Verbindung zum JMS-Provider herzustellen.

Korrekturmaßnahme: Wenn der JMS-Provider nicht mit einem traditionellen Abfragemodell, sondern mit einem auf dem JMS-Client beruhenden Modell implementiert wird, kann es sein, dass er keine Ausnahmebedingung auslöst, wenn bei einer Brokerverbindung 'receive()' aufgerufen wird. Sie können dieses Problem lösen, indem Sie die Eigenschaft 'jmsAsyncExceptionHandling' des konfigurierbaren JMSProviders-Service für diesen JMS-Provider auf 'true' setzen.

Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

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

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


ReferenzthemaReferenzthema | Version 8.0.0.5 | ac24877_