Es werden Java-Klassen-Fehlernachrichten ausgegeben, wenn Sie den Debugger starten
Szenario: Sie versuchen, auf einem Nachrichtenfluss den Debugger zu starten, aber der Debugger startet nicht, und es wird eine Reihe von Ereignisfehlern über Java-Klassen ausgegeben.
Erläuterung: Die wahrscheinlichste Ursache dieses Problems ist, dass Sie den Rational Agent Controller nicht installiert haben. Der Agent Controller ist zwar keine Voraussetzung für WebSphere Message Broker, er ist jedoch für den Message-Flow-Debugger erforderlich.
Lösung: Installieren Sie den Agent Controller.
Die Endlosnachricht "waiting for communication" wird ausgegeben, wenn Sie den
Debugger starten
Szenario: Nachdem Sie auf Start
Debugging (Debug starten) geklickt haben, wird ein Endlosfortschrittsanzeiger mit dem Titel "waiting for communication" (Warten auf Kommunikation) angezeigt. Im Informationsfenster wird die Nachricht "debug session started" (Debug-Sitzung gestartet) nicht angezeigt.
Erläuterung: Wenn der Nachrichtenfluss über Knoten mit ESQL-Anweisungen verfügt, wird er möglicherweise nicht implementiert, auch wenn die Anweisungen syntaktisch richtig sind. Der Grund dafür können beispielsweise mehrere Deklarationen oder nicht initialisierte Variablen sein (d. h. semantische Probleme, die der Parser nicht berücksichtigt). Überprüfen Sie immer das Ereignisprotokoll der Workbench, um sicherzustellen, dass die von Fehlern bereinigte Version Ihres Nachrichtenflusses implementiert wurde. Sie hat denselben Namen wie der ursprüngliche Nachrichtenfluss, mit dem Suffix _debug_.
Wenn der Nachrichtenfluss nicht richtig implementiert wird, kann der Debugger nicht mit dem Nachrichtenfluss kommunizieren, und der Endlosfortschrittsanzeiger wird angezeigt.
Lösung: Klicken Sie auf Abbrechen, um den Vorgang zu bereinigen und einen gültigen Status wiederherzustellen. Beheben Sie anschließend die Fehler, und wiederholen Sie den Vorgang. Testen Sie zur Überprüfung, ob der Nachrichtenfluss ohne den Debugger Einsetzungsvorgänge durchführen kann.
Der Debugger wird anscheinend gestoppt
Szenario: Sie beheben Fehler in einem Nachrichtenfluss und setzen den Vorgang nach einem Unterbrechungspunkt fort. Es scheint jedoch nichts zu passieren, und nach etwa einer Minute erscheint ein Fortschrittsanzeiger, der angibt, dass der Debugger auf eine Übertragung wartet.
Erläuterung: Dieses Problem kann zwei mögliche Ursachen haben:
Der Nachrichtenfluss kann auf einen zeitintensiven Vorgang gestoßen sein, z. B. eine umfangreiche Datenbankabfrage, die Sie einfach abwarten müssen.
Der Broker wurde beendet, oder es trat eine andere außergewöhnliche Bedingung auf, und die Datenübertragung wurde getrennt. Klicken Sie in diesem Fall auf Abbrechen, um die Debugsitzung zu stoppen.
Beim Debugging wird die Sitzung abnormal beendet
Szenario: Nach dem Debug eines Nachrichtenflusses wird die Sitzung abnormal beendet, und noch immer ist die Debug-Instanz des Nachrichtenflusses (mf_debug_) in der Ausführungsgruppe des Brokers eingesetzt. Sie befürchten, dass dies Auswirkungen auf die Ausführung des Nachrichtenflusses haben kann und möchten für die Ausführungsgruppe den ursprünglichen Zustand festlegen.
Erläuterung: Der nicht zugeordnete Nachrichtenfluss sollte sich so verhalten, wie das ein Fluss normalerweise tut, und die Debug-Knoten haben keine Auswirkung auf die Nachrichtenverarbeitung. Wenn der Nachrichtenfluss wenige Knoten enthält, wirkt sich eine Fehlerberichtigung außer auf seinen Namen nicht erkennbar auf den Nachrichtenfluss aus. Wenn Sie jedoch über einen großen Nachrichtenfluss verfügen (d. h. mehr als 15 Knoten oder mehrere untergeordnete Nachrichtenflüsse), führen Sie die Fehlerberichtigung wie unten beschrieben aus, da die Leistung der Nachrichtenverarbeitung beeinträchtigt werden kann.
Lösung: Implementieren Sie den Broker erneut.
Bei einer vollständigen erneuten Implementierung des Brokers müsste der verwaiste Nachrichtenfluss durch den ursprünglichen Nachrichtenfluss ersetzt werden. Wenn dies nicht geschieht, entfernen Sie den nicht zugeordneten Fluss aus der Ausführungsgruppe und setzen sie ein. Fügen Sie anschließend den Fluss hinzu, und setzen Sie ihn ein, um den ursprünglichen Status des Brokers vor der Debugsitzung wiederherzustellen.
Es wird eine Fehlernachricht angezeigt, die besagt, dass der Rational Agent Controller nicht installiert ist
Szenario: Sie verwenden den Debugger für Nachrichtenflüsse und es wird ein Fehler ausgegeben, der besagt, dass der Agent Controller nicht installiert ist oder dass Sie den falschen Hostnamen oder Port gewählt haben.
Sie haben den Agent Controller-Service gestartet, und Hostname und Port sind gültig.
Lösung: Schließen Sie die Workbench, öffnen Sie sie erneut, und wiederholen Sie den Befehl. Sie können auch versuchen, den Agent
Controller-Service zu stoppen und erneut zu starten.
Die Steuerkomponenten des Nachrichtenflusses können nicht ausgewählt werden
Szenario: Sie öffnen den Assistenten An Nachrichtenfluss-Steuerkomponente anhängen, es sind jedoch keine Nachrichtenfluss-Steuerkomponenten für den Host-Computer aufgeführt.
Lösung: Schließen Sie den Assistenten, starten Sie den Rational Agent Controller auf dem Server-Computer erneut, und öffnen Sie anschließend den Assistenten. Weitere Informationen finden Sie unter An Nachrichtenfluss-Steuerkomponente zum Debugging anhängen.
Es wird keine Liste der Ausführungsgruppen angezeigt
Szenario: Ihr Rational Agent Controller wurde gestartet, und Ihr Broker ist aktiv, Sie können die Liste mit den Ausführungsgruppen auf der Agent-Seite jedoch nicht sehen, wenn Sie eine Verbindung zum Debugger herstellen.
Lösung: Starten Sie den Agent Controller vor dem Broker. Starten Sie den Agent Controller erneut, und wiederholen Sie den Versuch, den Debugger anzuhängen.
Auf der Seite des Agenten werden die falschen Ausführungsgruppennamen angezeigt
Szenario: Beim Versuch, den Debugger anzuhängen, werden auf der Seite des Agenten die gleichen Ausführungsgruppennamen angezeigt.
Erläuterung: Der Rational Agent Controller hat den Agenten seit dem letzten Versuch, eine Verbindung zum Debugger herzustellen, nicht aktualisiert.
Lösung: Starten Sie den Agent Controller erneut, um die Liste zu aktualisieren.
Zuordnungsfehler bei gemeinsam genutztem Speicher unter AIX
Szenario: Ihr Rational Agent Controller wurde gestartet, Ihr Broker ist aktiv, und Sie erhalten die Fehlernachricht, dass die Zuordnung von gemeinsam genutztem Speicher fehlgeschlagen ist, nachdem eine Verbindung zwischen dem Broker und dem Agent Controller hergestellt wurde.
Erläuterung: Hierbei handelt es sich um einen häufig vorkommenden Ablauffehler, der auftritt, wenn eine Verbindung vom Agent Controller zum Broker hergestellt wird und der Broker noch nicht vollständig gestartet wurde.
Lösung: Warten Sie, bis der Broker vollständig gestartet wurde, bevor Sie ihn an den Fluss-Debugger anhängen. Sie können auch die Protokollstufe im Agent Controller auf 'DEBUG' oder 'INORMATION' setzen; dies lässt mehr Zeit für die Initialisierung des Brokers zu. Führen Sie folgende Schritte aus, um die Protokollstufe zu ändern.
Wechseln Sie zum Verzeichnis IBM Agent Controller-Installationsverzeichnis/config, und öffnen Sie die Konfigurationsdatei serviceconfig.xml.
Ändern Sie die Auszeichnung loggingLevel in 'Debug' oder 'Information'. Der Standardwert ist 'WARNING'.
Es wird eine Fehlernachricht angezeigt, die besagt, dass die Debugsitzung nicht
gestartet werden kann
Szenario: Sie versuchen, eine Debug-Sitzung erneut zu starten oder neu
aufzurufen, aber wenn Sie auf das grüne Debug-Symbol klicken, wird eine Fehlernachricht
angezeigt, die Folgendes besagt: Debugsitzung kann nicht gestartet werden.
Erläuterung: Wenn Sie auf das Debug-Symbol
klicken, wird die letzte Debugsitzung erneut gestartet. Dies schlägt fehl, wenn Sie zuvor
noch keine Debugsitzung erstellt haben. Es schlägt auch dann fehl, wenn der Broker und
die Ausführungsgruppe, die zuvor einer Debugsitzung zugeordnet waren, nicht mehr aktiv
sind oder erneut gestartet wurden. Die Sitzung kann nicht erneut zugeordnet werden, ohne
erneut eine Prozessinstanz des Brokers und der Ausführungsgruppe auszuwählen.
Lösung:
Schließen Sie die Fehlernachricht, und klicken Sie auf den
Abwärtspfeil unmittelbar rechts neben dem Debug-Symbol.
Wählen Sie die Angaben zu Broker und Ausführungsgruppe erneut aus, oder ändern
Sie die Angaben in der vorherigen Debugstartkonfiguration, indem Sie im Dropdown-Menü auf
Debug klicken und die vorherige Debugstartkonfiguration auswählen.
Weitere Informationen finden Sie im Abschnitt An Nachrichtenfluss-Steuerkomponente zum Debugging anhängen.
Beim Warten auf die Verbindung des Rational Agent Controllers wird das Zeitlimit überschritten
Szenario: Sie erhalten Fehlernachrichten, die besagen, dass der Rational Agent
Controller-Service nicht starten konnte und dass ein Zeitlimit überschritten wurde, während darauf gewartet wurde, dass der Agent Controller-Service verbunden wird.
Erläuterung: Es könnte sein, dass der Agent Controller die falsche Version der JVM verwendet.
Lösung: Stellen Sie sicher, dass eine unterstützte JVM verwendet wird. Um festzustellen, welche JVM verwendet wird, rufen Sie den Befehl java -version auf der Befehlszeile auf. Um das korrekte Ergebnis zu erhalten, muss dieser Befehl die ausführbare Datei von Java aufrufen, die zur Verwendung angegeben wurde, als der Agent Controller installiert wurde.
Der Debugger wird beim nächsten Unterbrechungspunkt nicht angehalten
Szenario: Der Message-Flow-Debugger wird beim nächsten Unterbrechungspunkt in Ihrem Nachrichtenfluss nicht angehalten.
Lösung: Gehen Sie folgendermaßen vor:
Überprüfen Sie, ob Ihre Steuerkomponente für den Datenfluss (DataFlowEngine) aktiv ist. Ist dies nicht der Fall, starten Sie sie erneut.
Überprüfen Sie die Eingabewarteschlange. Wenn Ihre Eingabewarteschlange die von der letzten Verwendung des Debuggers übriggebliebenen Nachrichten enthält, müssen Sie diese löschen, bevor Sie eine neue Nachricht senden.
Die Ausführung einer Nachricht wird an einem Unterbrechungspunkt nicht gestoppt
Szenario: Nach dem Anhängen an den Debugger wird die Ausführung einer Nachricht an einem Unterbrechungspunkt nicht gestoppt.
Erläuterung: Dies ist unter Umständen auf einen zeitlichen Ablauffehler zurückzuführen oder auf ein falsches Einstellen der Parameter für eine Debugsitzung.
Lösung: Gehen Sie folgendermaßen vor:
Überprüfen Sie die Einstellungen Ihrer Startkonfiguration und stellen Sie dabei sicher, dass Sie das richtige Nachrichtenflussprojekt, den richtigen Hostnamen und die richtige Nachrichtenflussengine für die Debugsitzung angegeben haben.
Starten Sie die Debugsitzung erneut.
Im Nachrichtenfluss-Editor treten Editierprobleme auf
Szenario: Es treten Editierprobleme auf, wenn Sie den Nachrichtenfluss-Editor verwenden, während Sie Fehler in einem Nachrichtenfluss beheben.
Lösung: Bearbeiten Sie keine Nachrichten, während der Flow-Debugger angehängt ist. Wenn Sie einen Nachrichtenfluss bearbeiten müssen, heben Sie die Verbindung zum Debugger auf, bearbeiten Sie den Nachrichtenfluss, und setzen Sie den Nachrichtenfluss anschließend erneut ein.
Editieren des MQ Nachrichtendeskriptors (MQMD) führt zu unerwartetem Verhalten im Debugger
Szenario: Sie bearbeiten Eigenschaften des Nachrichtendeskriptors (MQMD) im Nachrichtengruppeneditor, was jedoch zu unerwartetem Verhalten beim Debugger führt.
Erläuterung: Wenn Sie den Inhalt des MQMD-Descriptors bearbeiten, nehmen diese Felder einen bestimmten Wertbereich an. Sie müssen diese Bereiche kennen, bevor Sie die Eigenschaften bearbeiten. Wenn Sie nicht explizit den Wert dieser Felder angeben, nehmen sie Standardwerte an, und gewisse Felder wurden in der Nachricht möglicherweise nicht angegeben. Die Werte in den Feldern, die in der Nachricht nicht explizit festgelegt wurden, sind Standardwerte. Ändern Sie diese Werte nur, wenn sie ihre Bedeutung oder den möglichen Wertbereich kennen.
Bei der Fehlerbehebung in Ihrem Nachrichtenfluss können Sie den Nachrichteninhalt nicht sehen
Szenario: Sie verwenden den Debugger für Nachrichtenflüsse und können sehen, wie die Nachricht im Nachrichtenfluss übergeben wird, Sie können jedoch den Inhalt der Nachricht nicht sehen.
Lösung: Öffnen Sie die Ansicht 'Flussdebugnachricht'. Dazu klicken Sie auf Fenster > Sicht anzeigen > Sonstige > Nachrichtenfluss > Flussdebugnachricht, und anschließend klicken Sie auf OK.
Sie können die Namen der Nachrichtenflüsse in der Debugansicht nicht sehen
Szenario: Nach dem Anhängen des Debuggers an die Ausführungsgruppe können Sie die Namen der implementierten Nachrichtenflüsse in der Debugansicht nicht sehen.
Lösung:
Stoppen Sie den Broker, in dem die Ausführungsgruppe ausgeführt wird.
Starten Sie den Rational Agent Controller erneut, der auf dem gleichen System wie der Broker ausgeführt wird.
Starten Sie den Broker erneut.
Sie können die Namen der implementierten Flüsse in der Debugansicht nicht sehen
Szenario: Nach dem Herstellen einer Verbindung zur Ausführungsgruppe können Sie in der Debugansicht die Namen der implementierten Flüsse nicht sehen.
Erläuterung: Es könnte ein Ablauffehler vorliegen.
Lösung: Warten Sie, bis der Broker vollständig gestartet wurde, und versuchen Sie
erneut, eine Verbindung mit dem Debugger herzustellen, oder starten Sie den Rational Agent Controller, der auf demselben Computer wie der Broker ausgeführt wird, erneut, und starten Sie anschließend den Broker erneut.
Während des Debugvorgangs wird über einem Knoten ein Ausrufezeichen angezeigt
Szenario: Im Nachrichtenflusseditor wird während des Debugvorgangs ein
Ausrufezeichen (!) über einem Knoten angezeigt.
Erläuterung: Während des Debugvorgangs ist eine Ausnahmebedingung im
Knoten aufgetreten.
Lösung: Suchen Sie in der Ansicht 'Variablen' von
Ansicht 'Debug' unter 'ExceptionList' nach einer
Fehlernachricht, die den aufgetretenen Fehler beschreibt.
Die von WebSphere MQ unter z/OS gemeldete Einreihungsuhrzeit (PutTime) sowie weitere Uhrzeiten oder Zeitmarken sind inkonsistent
Szenario: Die von WebSphere MQ unter z/OS gemeldete Einreihungsuhrzeit (PutTime) sowie weitere Uhrzeiten oder Zeitmarken sind inkonsistent. Eine Differenz von ca. 20 Sekunden wurde an folgenden Stellen ermittelt:
Traces (einschließlich der vom Traceknoten entnommenen)
MQPUTTIME-Zeitmarke im MQMD-Header der Nachricht
Aus ESQL entnommene Zeitmarken (beispielsweise in einem Rechenknoten)
Erläuterung: WebSphere Message Broker meldet die Uhrzeit unter Verwendung der Weltzeit (Coordinated Universal Time, UTC), wobei keine Schaltsekunden berücksichtigt werden. Die unter z/OS von WebSphere MQ im MQMD-Header einer Nachricht gemeldete Nachrichteneinreihungszeit berücksichtigt jedoch Schaltsekunden, indem sie den im CVT-Feld angegebenen Wert für die Anzahl der Sekunden verwendet.
Diese Inkonsistenz kann Folgendes verursachen:
Probleme beim Debugging
Probleme mit Nachrichtenflüssen, wenn Sie den Nachrichtenfluss mit Hilfe von Zeitmarken steuern möchten
Falsche Informationen
Lösung: Setzen Sie den Wert im CVT-Feld so, dass er mit den Schaltsekunden der Weltzeit übereinstimmt. Alternativ können Sie einen Versatzwert hinzufügen, um das Lesen einer z/OS-Zeitmarke anzupassen. Fügen Sie z. B. 20 Sekunden hinzu, wenn Sie versuchen, die aktuelle Uhrzeit (CURRENT_TIME) in ESQL abzurufen.
Nach dem Debug können Sie einen Nachrichtenfluss nicht ändern
Szenario: Sie haben einen Debug durchgeführt, doch nun scheinen Ihre Nachrichten festzustecken. Wenn Sie eine neue Nachricht einreihen, geschieht nichts.
Erläuterung: Dies kann darauf zurückzuführen sein, dass eine Nachricht zurückgesetzt wurde, obwohl die Eigenschaft Backout requeue name (Name für Zurückstellungswarteschlange) Ihrer Eingabewarteschlange nicht festgelegt wurde.
Lösung: Setzen Sie die Eigenschaft Backout requeue
name (Name für Zurückstellungswarteschlange) auf einen gültigen Warteschlangennamen (z. B. den Namen der Eingabewarteschlange selbst), und die Blockierung Ihres Nachrichtenflusses wird aufgehoben.
Sie haben einen Nachrichtenfluss, in dem Fehler behoben wurden, erneut implementiert, aber die Implementierung wird blockiert
Szenario: Durch die Verwendung des Debuggers wurden in Ihrem Nachrichtenfluss Fehler gefunden. Sie haben den Nachrichtenfluss geändert und anschließend erneut implementiert, jetzt ist die Implementierung jedoch blockiert.
Lösung: Vergewissern Sie sich bei der erneuten Implementierung des Nachrichtenflusses in einer Ausführungsgruppe, dass die Ausführungsgruppe nicht mehr mit dem Debugger verbunden ist.
Die Nachricht wird weiterhin an einem Unterbrechungspunkt
ausgeführt.
Szenario: Die Nachrichtenverarbeitung wird fortgesetzt, wenn ein Unterbrechungspunkt auftritt.
Erläuterung: Dies ist unter Umständen auf einen zeitlichen Ablauffehler zurückzuführen oder auf ein falsches Einstellen der Parameter für eine Debugsitzung.
Lösung: Überprüfen Sie die Einstellungen Ihrer Startkonfiguration. Stellen Sie sicher, dass Sie das richtige Nachrichtenflussprojekt, den richtigen Hostnamen und die richtige Nachrichtenflussengine für die Debugsitzung angegeben haben. Starten Sie die Debugsitzung erneut.
Beim Kopieren einer Nachrichtenzuordnung in ein Nachrichtenflussprojekt werden Fehler generiert
Szenario: Beim Kopieren einer Nachrichtenzuordnung in ein Nachrichtenflussprojekt werden Fehler generiert.
Erläuterung: Sie haben vor dem Kopieren der Nachrichtenzuordnung nicht die richtigen Verweise für das Nachrichtenflussprojekt eingerichtet.
Lösung: Diese Fehler verbleiben in der Taskliste, selbst wenn Sie die Projektverweise unmittelbar nach dem Kopieren zurücksetzen. Führen Sie einen bereinigten Build des Nachrichtenflussprojekts aus.