Suggerimenti per la risoluzione dei problemi e il debugging

Questa sezione descrive alcune insidie comuni che potresti incontrare durante lo sviluppo di flussi di lavoro utilizzando for Java. AWS Flow Framework Fornisce inoltre alcuni suggerimenti su come diagnosticare i problemi ed eseguirne il debug.

Errori di compilazione

Se utilizzi l'opzione di tessitura in fase di compilazione di AspectJ, è possibile che si verifichino errori di compilazione in cui il compilatore non riesce a trovare le classi client generate per il flusso di lavoro e le attività. La causa probabile di tali errori di compilazione è che il generatore AspectJ ha ignorato i client generati durante la compilazione. Puoi risolvere questo problema rimuovendo AspectJ dal progetto e riattivandolo. Nota che dovrai procedere in tal modo ogni volta che le interfacce di flusso di lavoro o di attività cambiano. A causa di questo problema, ti consigliamo di utilizzare l'opzione di tessitura in fase di caricamento. Per ulteriori informazioni, consulta la sezione Configurazione diAWS Flow Frameworkper Java.

Errore di risorsa sconosciuta

Amazon SWF restituisce un errore di risorsa sconosciuto quando tenti di eseguire un'operazione su una risorsa che non è disponibile. Le cause più comuni di questo errore sono:

• Configuri un lavoratore con un dominio inesistente. Per risolvere questo problema, registra innanzitutto il dominio utilizzando la console Amazon SWF o l'API del servizio Amazon SWF.

• Tenti di creare task di esecuzione di flusso di lavoro o di attività che non sono stati registrati. Ciò può accadere se cerchi di creare l'esecuzione di flusso di lavoro prima che i lavoratori vengano eseguiti. Poiché i lavoratori registrano i relativi tipi quando vengono eseguiti per la prima volta, devi eseguirli almeno una volta prima di tentare di avviare le esecuzioni (o registrare manualmente i tipi utilizzando la console o l'API del servizio). Nota che dopo la registrazione dei tipi, puoi creare le esecuzioni anche se non vi sono lavoratori in esecuzione.

• Un lavoratore tenta di completare un task di cui si è già verificato il timeout. Ad esempio, se un lavoratore impiega troppo tempo a elaborare un'attività e supera un timeout, si verificherà un UnknownResource errore quando tenta di completare o fallire l'attività. I AWS Flow Framework lavoratori continueranno a sondare Amazon SWF ed elaborare attività aggiuntive. ma è comunque consigliabile modificare il timeout. A questo proposito, devi registrate una nuova versione del tipo di attività.

Eccezioni durante la chiamata di get() su una promessa

A differenza di Java Future, Promise è un costrutto non bloccante e la chiamata di get() su un argomento Promise non ancora pronto genererà un'eccezione anziché un blocco. Il modo corretto di usare a Promise consiste nel passarlo a un metodo asincrono (o a un'attività) e accedere al suo valore nel metodo asincrono. AWS Flow Framework for Java garantisce che un metodo asincrono venga chiamato solo quando tutti gli argomenti passati ad esso sono pronti. Promise Se ritieni che il tuo codice sia corretto o se ti imbatti in questo errore mentre esegui uno degli AWS Flow Framework esempi, probabilmente è dovuto al fatto che AspectJ non è configurato correttamente. Per ulteriori informazioni, consulta la sezione Configurazione diAWS Flow Frameworkper Java.

Flussi di lavoro non deterministici

Come descritto nella sezione Non determinismo, l'implementazione del tuo flusso di lavoro deve essere deterministica. Alcuni errori comuni che possono portare al non determinismo sono l'utilizzo dell'orologio di sistema, l'utilizzo di numeri casuali e la generazione di GUID. Poiché questi costrutti possono restituire valori differenti in momenti differenti, il flusso di controllo del flusso di lavoro può utilizzare percorsi diversi ogni volta che viene eseguito (per informazioni dettagliate, consulta le sezioni AWS Flow FrameworkConcetti di base: Esecuzione distribuita e Come si presenta). Se il framework rileva una condizione di non determinismo durante l'esecuzione del flusso di lavoro, verrà generata un'eccezione.

Problemi dovuti al controllo delle versioni

Quando si implementa una nuova versione del flusso di lavoro o dell'attività, ad esempio quando si aggiunge una nuova funzionalità, è necessario aumentare la versione del tipo utilizzando l'annotazione appropriata:, o. @Workflow @Activites @Activity In genere, quando vengono distribuite nuove versioni di un flusso di lavoro, alcune esecuzioni della versione esistente sono già in corso. Di conseguenza, devi assicurarti che i task siano trasmessi ai lavoratori con la versione appropriata del flusso di lavoro e delle attività. A questo proposito, devi utilizzare un set di elenchi di task differente per ogni versione. Ad esempio, puoi aggiungere il numero di versione al nome dell'elenco di task. In questo modo, i task appartenenti a differenti versioni del flusso di lavoro e delle attività sono assegnati ai lavoratori appropriati.

Risoluzione dei problemi e debug di un'esecuzione di flusso di lavoro

Il primo passaggio per la risoluzione dei problemi di esecuzione di un flusso di lavoro consiste nell'utilizzare la console Amazon SWF per esaminare la cronologia del flusso di lavoro. La cronologia del flusso di lavoro è un record completo e attendibile di tutti gli eventi che hanno modificato lo stato dell'esecuzione di flusso di lavoro. Questa cronologia è gestita da Amazon SWF ed è preziosa per la diagnosi dei problemi. La console Amazon SWF ti consente di cercare esecuzioni di flussi di lavoro e approfondire i singoli eventi della cronologia.

AWS Flow Framework fornisce una WorkflowReplayer classe che puoi usare per riprodurre localmente l'esecuzione di un flusso di lavoro ed eseguirne il debug. Utilizzando questa classe, è possibile eseguire il debug di esecuzioni di workflow chiuse e in esecuzione. WorkflowReplayersi affida alla cronologia memorizzata in Amazon SWF per eseguire la riproduzione. Puoi indirizzarlo all'esecuzione di un flusso di lavoro nel tuo account Amazon SWF o fornirgli gli eventi della cronologia (ad esempio, puoi recuperare la cronologia da Amazon SWF e serializzarla localmente per un uso successivo). La riproduzione di un'esecuzione di flusso di lavoro con WorkflowReplayer non ha alcun impatto sull'esecuzione in corso nel tuo account. L'intera riproduzione viene eseguita sul client. Puoi eseguire il debug del flusso di lavoro, creare punti di interruzione ed eseguire istruzioni utilizzando gli strumenti di debug abituali. Se utilizzi Eclipse, prendi in considerazione l'aggiunta di filtri Step ai pacchetti di filtri. AWS Flow Framework

Ad esempio, il seguente frammento di codice può essere utilizzato per riprodurre un'esecuzione di flusso di lavoro:

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 consente inoltre di ottenere un dump asincrono dei thread dell'esecuzione del flusso di lavoro. Questo dump fornisce gli stack di chiamate di tutti i task asincroni aperti. Queste informazioni possono essere utili per determinare quali task nell'esecuzione sono in sospeso e possibilmente bloccati. Per esempio:

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);
}

Perdita di task

A volte, è possibile che tu chiuda dei lavoratori e che ne avvii di nuovi in rapida successione per infine scoprire che i task sono recapitati ai vecchi lavoratori. Ciò può avvenire a seguito di condizioni di competizione nel sistema, il quale è ripartito su vari processi. Il problema può verificarsi anche quando esegui unit test in un ciclo ridotto oppure a seguito dell'arresto di un test in Eclipse nel caso in cui i gestori di chiusura non siano chiamati.

Per avere la certezza che il problema è in effetti dovuto al fatto che sono i vecchi lavoratori a ricevere i task, dovresti esaminare la cronologia del flusso di lavoro per determinare quale processo ha ricevuto il task che doveva essere recapitato al nuovo lavoratore. Ad esempio, l'evento DecisionTaskStarted nella cronologia contiene l'identità del lavoratore di flusso di lavoro che ha ricevuto il task. Il formato dell'ID utilizzato da Flow Framework è: {processId}@{host name}. Ad esempio, di seguito sono riportati i dettagli dell'DecisionTaskStartedevento nella console Amazon SWF per un'esecuzione di esempio:

Timestamp di evento	Mon Feb 20 11:52:40 GMT-800 2012
Identità	2276@ip-0A6C1DF5
ID evento pianificato	33

Per evitare questa situazione, utilizza elenchi di task differenti per ogni test. Valuta inoltre la possibilità di aggiungere un ritardo tra la chiusura dei vecchi lavoratori e l'avvio dei nuovi.