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. Auch wenn der Agent Controller für WebSphere Message Broker keine Voraussetzung ist, so stellt er doch eine Voraussetzung für den Debugger für Nachrichtenflüsse dar.
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. Die Ursache können beispielsweise mehrere Deklarationen oder nicht initialisierte Variablen sein (d. h. semantische Probleme, die der Syntax-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 eine Bereinigung durchzuführen und den Status zurückzusetzen, beheben Sie anschließend die Fehler, und wiederholen Sie den Vorgang. Überprüfen Sie, ob Ihr Nachrichtenfluss ohne den Debugger implementiert werden 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 geschehen, und nach ca. einer Minute wird ein Fortschrittsanzeiger angezeigt, der angibt, dass der Debugger auf eine Datenübertragung wartet.
Erläuterung: Dafür gibt es zwei mögliche Ursachen.
Der Nachrichtenfluss wird möglicherweise durch eine zeitintensive Operation verzögert, z. B. eine sehr umfangreiche Datenbankabfrage, so dass Sie einfach warten müssen, bis diese abgeschlossen ist.
Der Broker wurde beendet, oder es ist eine andere außergewöhnliche Bedingung aufgetreten, und die Datenübertragung wurde unterbrochen. Klicken Sie in diesem Fall auf Abbrechen, um die Debugsitzung zu stoppen.
Beim Debugging wird die Sitzung abnormal beendet
Szenario: Nach der Fehlerbehebung in einem Nachrichtenfluss wird die Sitzung abnormal beendet, und die Debuginstanz des Nachrichtenflusses (mf_debug_) ist immer noch in der Ausführungsgruppe des Brokers implementiert. Sie befürchten, dass sich dies negativ auf die Verarbeitung des Nachrichtenflusses auswirkt, und möchten die Ausführungsgruppe in ihren ursprünglichen Zustand zurückversetzen.
Erläuterung: Der verwaiste Nachrichtenfluss müsste sich so verhalten, wie der Nachrichtenfluss sich normalerweise verhalten hätte, und die Debugknoten 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 die gewünschte Wirkung hat, entfernen Sie den verwaisten Nachrichtenfluss aus der Ausführungsgruppe, führen Sie eine Implementierung durch, und fügen Sie anschließend den Nachrichtenfluss hinzu. Führen Sie dann erneut eine Implementierung durch, um den ursprünglichen Zustand 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.
Nachrichtenfluss-Steuerkomponenten stehen nicht zur Auswahl zur Verfügung
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 Nachrichtenflussengine anhängen.
Sie können die Liste mit den Ausführungsgruppen nicht sehen
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 Ihre Agent Controller-Services, bevor Sie den Broker starten. Starten Sie den Agent Controller erneut, und versuchen Sie erneut, eine Verbindung herzustellen.
Auf der Seite des Agenten werden die falschen Ausführungsgruppennamen angezeigt
Szenario: Wenn Sie versuchen, eine Verbindung zum Debugger herzustellen, werden auf der Agent-Seite dieselben 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: Dies ist ein allgemeiner Ablaufsteuerungsfehler, der auftritt, wenn der Agent Controller mit dem Broker verbunden wird, wenn der Broker noch nicht vollständig gestartet wurde.
Lösung: Warten Sie, bis der Broker vollständig gestartet wurde, bevor Sie ihn mit dem Fluss-Debugger verbinden. 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 Nachrichtenflussengine 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 hält nicht am nächsten Unterbrechungspunkt an
Szenario: Der Debugger für Nachrichtenflüsse hält nicht am nächsten Unterbrechungspunkt in Ihrem Nachrichtenfluss an.
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 Nachricht wird weiterhin an einem Unterbrechungspunkt
ausgeführt.
Szenario: Die Nachricht wird nach Herstellung einer Verbindung mit dem Debugger weiterhin an einem Unterbrechungspunkt
ausgeführt.
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: Versuchen Sie nicht, die Nachricht zu bearbeiten, während eine Verbindung zum Fluss-Debugger besteht. 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: Dies ist unter Umständen auf einen zeitlichen Ablauffehler zurückzuführen.
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 Fehler behoben, aber Ihr Nachrichtenfluss scheint jetzt blockiert zu sein. 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: Sie haben in Ihrem Nachrichtenfluss mit Hilfe des Debuggers 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.