Fehlerbehebung bei JMS-Knoten

Sie können möglicher Probleme mit JMS-Knoten prüfen.

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

Falls eine Nachricht nicht vom JMSInput-Knoten verarbeitet werden kann oder als Bestandteil einer globalen Transaktion zurückgesetzt wurde, wird die Nachricht in das Quellenziel zurückgesetzt. In diesem Fall wird die Nachricht erneut an den JMSInput-Knoten zugestellt.

Damit die Verarbeitung gültiger Nachrichten nicht durch ungültig formatierte Nachrichten unterbrochen wird, können die Knoteneigenschaften folgendermaßen konfiguriert werden:

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 gesteuert wird, wann eine Nachricht an das Rücksetzziel gesendet wird. Der Schwellenwert 3 bedeutet Folgendes: Wenn der JMSInput-Knoten 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.

Problemdiagnose bei der Verwendung global koordinierter Transaktionen

Zusätzlich zum Servicetrace des Brokers wird ein anderes Traceprotokoll zur Ermittlung von Fehlern bereitgestellt, die bei der Beteiligung eines JMSInput- oder JMSOutput-Knotens an einer globalen Nachrichtenflusstransaktion auftreten könnten. Das bedeutet, dass für mindestens einen JMSInput- oder JMSOutput-Knoten im Nachrichtenfluss die Eigenschaft Transaktionsmodus auf global und die Nachrichtenflusseigenschaft Koordinierte Transaktion auf ja gesetzt wurde.

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 folgendermaßen 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.

      Durch den oben genannten Beispielwert für die Variable 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 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.

Dieses Problem gilt nicht unter z/OS.

Probleme mit verwalteten JNDI-Objekten

Problembeschreibung: Der JMSInput- oder JMSOutput-Knoten kann die Ausgangskontext-Factory 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 den Ausganskontext, den Namen der Verbindungsfactory und die Quellenwarteschlange bzw. die 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 Name der Ausgangskontext-Factory keinen Dateipfad enthält.
  6. Stellen Sie sicher, dass eine in den Knoteneigenschaften angegebene JMS-Zieladresse (Thema oder Quellenwarteschlange bzw. Zielwarteschlange) in den verwalteten JNDI-Objekten vorhanden ist.
  7. Stellen Sie sicher, dass sich die JAR-Java-Dateien des JMS-Providers auf verteilten Plattformen 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 versucht 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.

Problembeschreibung: Ein JMSInput- oder JMSOutput-Knoten kann keine Verbindung zu einem JMS-Provider erstellen, und es wird die Fehlermeldung 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 Plattformen 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 JMSInput- oder JMSOutput-Knoten kann keine JMS-Zieladresse aufrufen, und es wird die Fehlermeldung 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 oder Quellenwarteschlange bzw. Zieladressenwarteschlange) 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.
Zugehörige Konzepte
JMS-Transaktionalität
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Letzte Aktualisierung : 2009-02-17 15:28:27

ac24877_