Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Tipps zur Fehlersuche und Debugging

In diesem Abschnitt werden einige häufige Fallstricke beschrieben, die bei der Entwicklung von Workflows mit AWS Flow Framework für Java auftreten können. Außerdem erhalten Sie einige Tipps, die Ihnen bei der Diagnose und der Behebung von Problemen helfen.

Kompilierungsfehler

Wenn Sie die AspectJ-Compile-Time-Weaving-Option verwenden, treten möglicherweise Kompilierzeitfehler auf, bei denen der Compiler die generierten Client-Klassen für Ihren Workflow und Ihre Aktivitäten nicht finden kann. Die wahrscheinliche Ursache solcher Kompilierfehler ist, dass der AspectJ-Builder die generierten Clients während der Kompilierung ignoriert hat. Sie können dieses Problem beheben, indem Sie die AspectJ-Funktion aus dem Projekt entfernen und erneut aktivieren. Beachten Sie, dass Sie dies jedes Mal durchführen müssen, wenn sich Ihre Workflow- oder Aktivitätsschnittstellen ändern. Aufgrund dieses Problems wird empfohlen, stattdessen die Load-Time-Weaving-Option zu verwenden. Weitere Details finden Sie im Abschnitt Einrichten vonAWS Flow Frameworkfür Java.

Unbekannter Ressourcenfehler

Amazon SWF gibt einen unbekannten Ressourcenfehler zurück, wenn Sie versuchen, eine Operation für eine Ressource auszuführen, die nicht verfügbar ist. Die häufigen Ursachen für diesen Fehler sind:

Ausnahmen beim Aufrufen von get() für ein Promise-Objekt

Anders als Java Future ist Promise ein blockierungsfreies Konstrukt und das Aufrufen von get() für ein noch nicht bereites Promise-Objekt führt zu einer Ausnahme anstelle einer Blockierung. Der richtige Weg, eine zu verwenden, Promise besteht darin, sie an eine asynchrone Methode (oder eine Aufgabe) zu übergeben und auf ihren Wert in der asynchronen Methode zuzugreifen. AWS Flow Framework für Java stellt sicher, dass eine asynchrone Methode nur aufgerufen wird, wenn alle an sie übergebenen Promise Argumente bereit sind. Wenn Sie der Meinung sind, dass Ihr Code korrekt ist, oder wenn Sie bei der Ausführung eines der AWS Flow Framework Beispiele darauf stoßen, liegt dies höchstwahrscheinlich daran, dass AspectJ nicht ordnungsgemäß konfiguriert ist. Details hierzu finden Sie im Abschnitt Einrichten vonAWS Flow Frameworkfür Java.

Nicht-deterministische Workflows

Wie im Abschnitt Nichtdeterminismus beschrieben, muss die Implementierung Ihres Workflows deterministisch sein. Zu den häufigen Fehlern, die zu Nichtdeterminismus führen können, gehören die Verwendung von Systemuhren, die Verwendung zufälliger Zahlen und die Generierung von GUIDs. Da diese Konstrukte möglicherweise unterschiedliche Werte zu unterschiedlichen Zeiten zurückgeben, nimmt der Kontrollfluss Ihres Workflows unter Umständen unterschiedliche Pfade bei jeder einzelnen Ausführung (Details finden Sie in den Abschnitten AWS Flow FrameworkGrundkonzepte: Verteilte Ausführung und Blick unter die Haube). Wenn das Framework während der Ausführung des Workflows Nichtdeterminismus erkennt, wird eine Ausnahme ausgelöst.

Probleme aufgrund von Versioning

Wenn Sie eine neue Version Ihres Workflows oder Ihrer Aktivität implementieren, z. B. wenn Sie ein neues Feature hinzufügen, sollten Sie die Version des Typs mithilfe der entsprechenden Anmerkung erhöhen: @Workflow@Activites, oder @Activity. Wenn neue Versionen eines Workflows bereitgestellt werden, haben Sie oft Ausführungen der bestehenden Version, die bereits ausgeführt werden. Sie müssen daher sicherstellen, dass Worker mit der entsprechenden Version Ihres Workflows und Ihrer Aktivitäten die Aufgabe erhalten. Sie können dies erreichen, indem Sie verschiedene Aufgabenlisten für jede Version verwenden. Sie können beispielsweise die Versionsnummer an den Namen der Aufgabenliste anfügen. Dadurch wird sichergestellt, dass Aufgaben, die zu unterschiedlichen Versionen des Workflows und der Aktivitäten gehören, den entsprechenden Workern zugewiesen werden.

Fehlerbehebung und Debugging einer Workflow-Ausführung

Der erste Schritt bei der Fehlerbehebung bei einer Workflow-Ausführung besteht darin, die Amazon SWF-Konsole zu verwenden, um sich den Workflow-Verlauf anzusehen. Der Workflow-Verlauf ist ein kompletter und autoritativer Datensatz aller Ereignissen, die den Ausführungsstatus der Workflow-Ausführung geändert haben. Dieser Verlauf wird von Amazon SWF verwaltet und ist für die Diagnose von Problemen von unschätzbar. Mit der Amazon SWF-Konsole können Sie nach Workflow-Ausführungen suchen und einzelne Verlaufsereignisse aufschlüsseln.

AWS Flow Framework bietet eine WorkflowReplayer Klasse, mit der Sie eine Workflow-Ausführung lokal wiederholen und debuggen können. Mit dieser Klasse können Sie geschlossene und ausgeführte Workflow-Ausführungen debuggen. stützt WorkflowReplayer sich auf den in Amazon SWF gespeicherten Verlauf, um die Wiederholung durchzuführen. Sie können ihn auf eine Workflow-Ausführung in Ihrem Amazon SWF-Konto verweisen oder ihm die Verlaufsereignisse bereitstellen (Sie können beispielsweise den Verlauf von Amazon SWF abrufen und ihn lokal zur späteren Verwendung serialisieren). Wenn Sie eine Workflow-Ausführung mithilfe von WorkflowReplayer erneut abspielen, wirkt sich dies nicht auf die Workflow-Ausführung aus, die in Ihrem Konto ausgeführt wird. Das erneute Abspielen findet vollständig auf dem Client statt. Sie können wie gewohnt mithilfe Ihrer Debugging-Tools den Workflow debuggen, Haltepunkte erstellen und in den Code hineinzuspringen. Wenn Sie Eclipse verwenden, sollten Sie Schrittfilter zum Filtern von AWS Flow Framework Paketen hinzufügen.

Der folgende Codeausschnitt beispielsweise kann verwendet werden, um eine Workflow-Ausführung erneut abzuspielen:

String workflowId = "testWorkflow";
String runId = "<run id>";
Class<HelloWorldImpl> workflowImplementationType = HelloWorldImpl.class;
WorkflowExecution workflowExecution = new WorkflowExecution();
workflowExecution.setWorkflowId(workflowId);
workflowExecution.setRunId(runId);

WorkflowReplayer<HelloWorldImpl> replayer = new WorkflowReplayer<HelloWorldImpl>(
    swfService, domain, workflowExecution, workflowImplementationType);

System.out.println("Beginning workflow replay for " + workflowExecution);
Object workflow = replayer.loadWorkflow();
System.out.println("Workflow implementation object:");
System.out.println(workflow);
System.out.println("Done workflow replay for " + workflowExecution);

AWS Flow Framework Mit können Sie auch einen asynchronen Thread-Dump Ihrer Workflow-Ausführung abrufen. Dieser Thread-Dump liefert Ihnen die Aufruflisten aller offenen asynchronen Aufgaben. Diese Informationen können beim Bestimmen, welche Aufgaben in der Ausführung noch ausstehen und möglicherweise hängen geblieben sind, helfen. Beispielsweise:

String workflowId = "testWorkflow";
String runId = "<run id>";
Class<HelloWorldImpl> workflowImplementationType = HelloWorldImpl.class;
WorkflowExecution workflowExecution = new WorkflowExecution();
workflowExecution.setWorkflowId(workflowId);
workflowExecution.setRunId(runId);

WorkflowReplayer<HelloWorldImpl> replayer = new WorkflowReplayer<HelloWorldImpl>(
    swfService, domain, workflowExecution, workflowImplementationType);

try {
    String flowThreadDump = replayer.getAsynchronousThreadDumpAsString();
    System.out.println("Workflow asynchronous thread dump:");
    System.out.println(flowThreadDump);
}
catch (WorkflowException e) {
    System.out.println("No asynchronous thread dump available as workflow has failed: " + e);
}

Verlorene Aufgaben

Manchmal fahren Sie vielleicht in kurzer Abfolge Worker herunter und starten neue, nur um festzustellen, dass Aufgaben an dieselben alten Worker übermittelt werden. Dies kann aufgrund von Race Conditions im System passieren, das über mehrere Prozesse hinweg verteilt ist. Das Problem kann außerdem auftreten, wenn Sie Komponententests in einer engen Schleife ausführen. Das Beenden eines Tests in Eclipse kann dies manchmal auch verursachen, da heruntergefahrene Handler möglicherweise nicht aufgerufen werden.

Um sicherzustellen, dass das Problem tatsächlich darauf zurückzuführen ist, dass alte Worker Aufgaben erhalten, sollten Sie sich den Workflow-Verlauf ansehen, um zu bestimmen, welcher Prozess die Aufgabe erhalten hat, von der Sie erwartet hatten, dass der neue Worker sie erhält. Beispielsweise enthält das DecisionTaskStarted-Ereignis im Verlauf die Identität des Workflow-Workers, der die Aufgabe erhalten hat. Die vom Flow Framework verwendete ID weist folgendes Format auf: {processId}@{host name}. Im Folgenden finden Sie beispielsweise die Details des DecisionTaskStarted Ereignisses in der Amazon SWF-Konsole für eine Beispielausführung:

Um diese Situation zu vermeiden, verwenden Sie unterschiedliche Aufgabenlisten für jeden Test. Ziehen Sie außerdem in Betracht, eine Verzögerung zwischen dem Herunterfahren alter Worker und dem Starten neuer Worker hinzuzufügen.