Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Relance des activités ayant échoué

Les activités échouent parfois pour des raisons éphémères comme une perte temporaire de connectivité. L'activité peut réussir à un autre moment. La méthode appropriée pour résoudre des échecs d'activité consiste donc souvent à relancer l'activité, peut-être plusieurs fois.

Il existe différentes stratégies pour relancer des activités ; celle qui convient le mieux dépend des détails de votre flux de travail. Les stratégies se répartissent en trois catégories de base :

Les sections suivantes expliquent comment implémenter ces stratégies. Les exemples de exécuteurs de flux de travail utilisent tous une activité unique, unreliableActivity, qui exécute de façon aléatoire les actions suivantes :

Retry-Until-Success Stratégie

La stratégie de nouvelle tentative la plus simple consiste à relancer chaque fois l'activité jusqu'à ce que celle-ci réussisse. Le modèle de base est le suivant :

Le flux de travail suivant met en œuvre la retry-until-success stratégie. L'interface de flux de travail est implémentée dans RetryActivityRecipeWorkflow et comporte une méthode, runUnreliableActivityTillSuccess, qui est le point d'entrée du flux de travail. L'exécuteur de flux de travail est implémenté dans RetryActivityRecipeWorkflowImpl, comme suit :

public class RetryActivityRecipeWorkflowImpl
    implements RetryActivityRecipeWorkflow {

    @Override
    public void runUnreliableActivityTillSuccess() {
        final Settable<Boolean> retryActivity = new Settable<Boolean>();

        new TryCatch() {
            @Override
            protected void doTry() throws Throwable {
                Promise<Void> activityRanSuccessfully
                    = client.unreliableActivity();
                setRetryActivityToFalse(activityRanSuccessfully, retryActivity);
            }

            @Override
            protected void doCatch(Throwable e) throws Throwable {
                retryActivity.set(true);
            }
        };
        restartRunUnreliableActivityTillSuccess(retryActivity);
    }

    @Asynchronous
    private void setRetryActivityToFalse(
            Promise<Void> activityRanSuccessfully,
            @NoWait Settable<Boolean> retryActivity) {
        retryActivity.set(false);
    }

    @Asynchronous
    private void restartRunUnreliableActivityTillSuccess(
            Settable<Boolean> retryActivity) {
        if (retryActivity.get()) {
            runUnreliableActivityTillSuccess();
        }
    }
}

Le flux de travail fonctionne comme suit :

Stratégie de nouvelle tentative exponentielle

Avec la stratégie de nouvelle tentative exponentielle, l'infrastructure exécute à nouveau une activité ayant échoué après une période de temps spécifiée, N secondes. Si cette tentative échoue, l'infrastructure exécute à nouveau l'activité après 2N secondes, puis après 4N secondes, et ainsi de suite. Comme le temps d'attente peut devenir très long, vous arrêtez généralement les nouvelles tentatives après un certain temps plutôt que de continuer indéfiniment.

L'infrastructure fournit trois façons d'implémenter une stratégie de nouvelle tentative exponentielle :

Toutes les approches prennent en charge les options de configuration suivantes, où les valeurs de temps sont exprimées en secondes :

Les sections suivantes décrivent les différentes façons d'implémenter une stratégie de nouvelle tentative exponentielle.

Réessayer de façon exponentielle avec @ ExponentialRetry

La façon la plus simple d'implémenter une stratégie de nouvelle tentative exponentielle pour une activité est d'appliquer une annotation @ExponentialRetry à l'activité dans la définition d'interface. Si l'activité échoue, l'infrastructure gère automatiquement le processus de nouvelle tentative en fonction des valeurs d'option spécifiées. Le modèle de base est le suivant :

L'exécuteur de flux de travail ExponentialRetryAnnotationWorkflow implémente la stratégie de nouvelle tentative exponentielle en utilisant une annotation @ExponentialRetry. Il utilise une activité unreliableActivity dont la définition d'interface est implémentée dans ExponentialRetryAnnotationActivities comme suit :

@Activities(version = "1.0")
@ActivityRegistrationOptions(
    defaultTaskScheduleToStartTimeoutSeconds = 30,
    defaultTaskStartToCloseTimeoutSeconds = 30)
public interface ExponentialRetryAnnotationActivities {
    @ExponentialRetry(
        initialRetryIntervalSeconds = 5,
        maximumAttempts = 5,
        exceptionsToRetry = IllegalStateException.class)
    public void unreliableActivity();
}

Les options @ExponentialRetry spécifient la stratégie suivante :

L'interface de flux de travail est implémentée dans RetryWorkflow et comporte une méthode, process, qui est le point d'entrée du flux de travail. L'exécuteur de flux de travail est implémenté dans ExponentialRetryAnnotationWorkflowImpl, comme suit :

public class ExponentialRetryAnnotationWorkflowImpl implements RetryWorkflow {
    public void process() {
        handleUnreliableActivity();
    }

    public void handleUnreliableActivity() {
        client.unreliableActivity();
    }
}

Le flux de travail fonctionne comme suit :

Si l'activité échoue en déclenchant IllegalStateException, l'infrastructure exécute automatiquement la stratégie de nouvelle tentative spécifiée dans ExponentialRetryAnnotationActivities.

Réessai exponentiel avec la classe RetryDecorator

@ExponentialRetry est simple à utiliser. Par contre, la configuration est statique et définie lors de la compilation. L'infrastructure utilise donc la même stratégie de nouvelle tentative chaque fois que l'activité échoue. Vous pouvez implémenter une stratégie de nouvelle tentative exponentielle plus flexible à l'aide de la classe RetryDecorator, qui vous permet de spécifier la configuration pendant l'exécution et de la modifier si nécessaire. Le modèle de base est le suivant :

Si l'activité échoue, l'infrastructure la relance automatiquement en fonction de la configuration de l'objet ExponentialRetryPolicy. Vous pouvez modifier la configuration de nouvelle tentative si nécessaire en modifiant cet objet.

L'implémentation de flux de travail suivante montre comment utiliser la classe RetryDecorator pour implémenter une stratégie de nouvelle tentative exponentielle. Elle utilise une activité unreliableActivity qui ne comporte pas d'annotation @ExponentialRetry. L'interface de flux de travail est implémentée dans RetryWorkflow et comporte une méthode, process, qui est le point d'entrée du flux de travail. L'exécuteur de flux de travail est implémenté dans DecoratorRetryWorkflowImpl, comme suit :

public class DecoratorRetryWorkflowImpl implements RetryWorkflow {
   ...
  public void process() {
      long initialRetryIntervalSeconds = 5;
      int maximumAttempts = 5;
      ExponentialRetryPolicy retryPolicy = new ExponentialRetryPolicy(
              initialRetryIntervalSeconds).withMaximumAttempts(maximumAttempts);

      Decorator retryDecorator = new RetryDecorator(retryPolicy);
      client = retryDecorator.decorate(RetryActivitiesClient.class, client);
      handleUnreliableActivity();
  }

  public void handleUnreliableActivity() {
      client.unreliableActivity();
  }
}

Le flux de travail fonctionne comme suit :

Si une activité échoue, l'infrastructure la relance en fonction de la configuration spécifiée à l'étape 1.

Réessai exponentiel avec la classe AsyncRetryingExecutor

La classe RetryDecorator offre plus de flexibilité pour la configuration du processus de nouvelle tentative que @ExponentialRetry, mais l'infrastructure exécute toujours les nouvelles tentatives automatiquement, en fonction de la configuration actuelle de l'objet ExponentialRetryPolicy. Une approche plus souple consiste à utiliser la classe AsyncRetryingExecutor. En plus de vous permettre de configurer le processus de nouvelle tentative pendant l'exécution, l'infrastructure appelle une méthode AsyncRunnable.run implémentée par l'utilisateur pour exécuter chaque nouvelle tentative au lieu de simplement exécuter l'activité.

Le modèle de base est le suivant :

Le flux de travail suivant montre comment utiliser la classe AsyncRetryingExecutor pour implémenter une stratégie de nouvelle tentative exponentielle. Il utilise la même activité unreliableActivity que le flux de travail DecoratorRetryWorkflow présenté précédemment. L'interface de flux de travail est implémentée dans RetryWorkflow et comporte une méthode, process, qui est le point d'entrée du flux de travail. L'exécuteur de flux de travail est implémenté dans AsyncExecutorRetryWorkflowImpl, comme suit :

public class AsyncExecutorRetryWorkflowImpl implements RetryWorkflow {
  private final RetryActivitiesClient client = new RetryActivitiesClientImpl();
  private final DecisionContextProvider contextProvider = new DecisionContextProviderImpl();
  private final WorkflowClock clock = contextProvider.getDecisionContext().getWorkflowClock();

  public void process() {
      long initialRetryIntervalSeconds = 5;
      int maximumAttempts = 5;
      handleUnreliableActivity(initialRetryIntervalSeconds, maximumAttempts);
  }
  public void handleUnreliableActivity(long initialRetryIntervalSeconds, int maximumAttempts) {

      ExponentialRetryPolicy retryPolicy = new ExponentialRetryPolicy(initialRetryIntervalSeconds).withMaximumAttempts(maximumAttempts);
      final AsyncExecutor executor = new AsyncRetryingExecutor(retryPolicy, clock);

      new TryCatch() {
          @Override
          protected void doTry() throws Throwable {
              executor.execute(new AsyncRunnable() {
                  @Override
                  public void run() throws Throwable {
                      client.unreliableActivity();
                  }
              });
          }
          @Override
          protected void doCatch(Throwable e) throws Throwable {
          }
      };
  }
}

Le flux de travail fonctionne comme suit :

Pour en savoir plus sur l'utilisation de la classe TryCatch pour gérer des erreurs, consultez AWS Flow Framework pour les exceptions Java.

Stratégie de nouvelle tentative personnalisée

L'approche la plus flexible pour réessayer les activités ayant échoué est une stratégie personnalisée, qui appelle de manière récursive une méthode asynchrone qui exécute la nouvelle tentative, un peu comme la stratégie. retry-until-success Par contre, au lieu de relancer simplement l'activité, vous implémentez une logique personnalisée qui décide si chaque nouvelle tentative successive doit être exécutée et de quelle façon. Le modèle de base est le suivant :

Le flux de travail suivant montre comment implémenter une stratégie de nouvelle tentative personnalisée. Il utilise la même activité unreliableActivity que les flux de travail DecoratorRetryWorkflow et AsyncExecutorRetryWorkflow. L'interface de flux de travail est implémentée dans RetryWorkflow et comporte une méthode, process, qui est le point d'entrée du flux de travail. L'exécuteur de flux de travail est implémenté dans CustomLogicRetryWorkflowImpl, comme suit :

public class CustomLogicRetryWorkflowImpl implements RetryWorkflow {
  ...
  public void process() {
      callActivityWithRetry();
  }
  @Asynchronous
  public void callActivityWithRetry() {
      final Settable<Throwable> failure = new Settable<Throwable>();
      new TryCatchFinally() {
          protected void doTry() throws Throwable {
              client.unreliableActivity();
          }
          protected void doCatch(Throwable e) {
              failure.set(e);
          }
          protected void doFinally() throws Throwable {
              if (!failure.isReady()) {
                  failure.set(null);
              }
          }
      };
      retryOnFailure(failure);
  }
  @Asynchronous
  private void retryOnFailure(Promise<Throwable> failureP) {
      Throwable failure = failureP.get();
      if (failure != null && shouldRetry(failure)) {
          callActivityWithRetry();
      }
  }
  protected Boolean shouldRetry(Throwable e) {
      //custom logic to decide to retry the activity or not
      return true;
  }
}

Le flux de travail fonctionne comme suit :