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.

Wiederholen fehlgeschlagener Aktivitäten

Gelegentlich schlagen Aktivitäten aus temporären Gründen fehl, z. B. aufgrund eines vorübergehenden Verbindungsverlusts. In anderen Fällen wird die Aktivität möglicherweise erfolgreich durchgeführt, daher besteht das geeignete Verfahren zum Umgang mit dem Aktivitätsfehler häufig im (ggf. mehrmaligen) Wiederholen der Aktivität.

Es gibt verschiedene Strategien zum Wiederholen von Aktivitäten. Welche am besten geeignet ist, hängt von den Details in Ihrem Workflow ab. Die Strategien lassen sich grundsätzlich in drei Kategorien einteilen:

In den folgenden Abschnitten wird die Implementierung dieser Strategien beschrieben. In diesem Beispiel nutzen die Workflow-Worker alle eine einzige Aktivität, unreliableActivity, die willkürlich eine der folgenden Verhaltensweisen zeigt:

Retry-Until-Success Strategie

Die einfachste Wiederholungsstrategie besteht darin, die Aktivität nach jedem Fehler zu wiederholen, bis sie schließlich erfolgreich durchgeführt werden kann. Das grundlegende Muster ist:

Der folgende Workflow implementiert die retry-until-success Strategie. Die Workflow-Schnittstelle wird in RetryActivityRecipeWorkflow implementiert und enthält die Methode runUnreliableActivityTillSuccess, die den Eintrittspunkt des Workflows darstellt. Der Workflow-Worker wird in RetryActivityRecipeWorkflowImpl wie folgt implementiert:

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

Der Workflow funktioniert folgendermaßen:

Exponentielle Wiederholungsstrategie

Bei der exponentiellen Wiederholungsstrategie führt das Framework eine fehlgeschlagene Aktivität nach einem festgelegten Zeitraum (N Sekunden) erneut aus. Schlägt dieser Versuch fehl, wiederholt das Framework die Aktivität nach 2N Sekunden, dann nach 4N Sekunden usw. Da die Wartezeit sehr lang werden kann, werden Sie die Wiederholungen nicht endlos fortsetzen, sondern den Vorgang irgendwann beenden.

Das Framework bietet drei Möglichkeiten zur Implementierung einer exponentiellen Wiederholungsstrategie:

Alle Ansätze unterstützen folgende Konfigurationsoptionen, wobei die Werte für die Zeit in Sekunden angegeben werden:

In den folgenden Abschnitten werden die verschiedenen Methoden zur Implementierung einer exponentiellen Wiederholungsstrategie beschrieben.

Exponentieller Wiederholungsversuch mit @ ExponentialRetry

Die einfachste Möglichkeit zur Implementierung einer exponentiellen Wiederholungsstrategie für eine Aktivität ist die Anwendung einer @ExponentialRetry -Anmerkung auf die Aktivität in der Schnittstellendefinition. Schlägt die Aktivität fehl, verarbeitet das Framework den Wiederholungsvorgang automatisch basierend auf den festgelegten Optionen. Das grundlegende Muster ist:

Der ExponentialRetryAnnotationWorkflow-Workflow-Worker implementiert die exponentielle Wiederholungsstrategie durch Verwendung einer @ExponentialRetry-Anmerkung. Er verwendet eine unreliableActivity-Aktivität, deren Schnittstellendefinition wie folgt in ExponentialRetryAnnotationActivities implementiert wird:

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

Die @ExponentialRetry-Optionen legen folgende Strategie fest:

Die Workflow-Schnittstelle wird in RetryWorkflow implementiert und enthält die Methode process, die den Eintrittspunkt des Workflows darstellt. Der Workflow-Worker wird in ExponentialRetryAnnotationWorkflowImpl wie folgt implementiert:

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

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

Der Workflow funktioniert folgendermaßen:

Schlägt die Aktivität fehl, indem IllegalStateException ausgegeben wird, führt das Framework automatisch die in ExponentialRetryAnnotationActivities festgelegte Wiederholungsstrategie aus.

Exponentielle Wiederholung mit der Klasse RetryDecorator

@ExponentialRetry ist benutzerfreundlich. Allerdings ist die Konfiguration statisch und wird bei der Kompilierung festgelegt, sodass das Framework bei jedem Fehler der Aktivität dieselbe Wiederholungsstrategie anwendet. Sie können eine flexiblere exponentielle Wiederholungsstrategie implementieren, indem Sie die RetryDecorator-Klasse verwenden, mit der Sie die Konfiguration zur Laufzeit festlegen und bei Bedarf ändern können. Das grundlegende Muster ist:

Schlägt die Aktivität fehl, wiederholt das Framework die Aktivität basierend auf der ExponentialRetryPolicy-Objektkonfiguration. Sie können die Wiederholungskonfiguration bei Bedarf ändern, indem Sie dieses Objekt anpassen.

Die folgende Workflow-Implementierung zeigt, wie die RetryDecorator-Klasse verwendet wird, um eine exponentielle Wiederholungsstrategie zu implementieren. Sie verwendet eine unreliableActivity-Aktivität, die nicht über eine @ExponentialRetry-Anmerkung verfügt. Die Workflow-Schnittstelle wird in RetryWorkflow implementiert und enthält die Methode process, die den Eintrittspunkt des Workflows darstellt. Der Workflow-Worker wird in DecoratorRetryWorkflowImpl wie folgt implementiert:

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

Der Workflow funktioniert folgendermaßen:

Schlägt die Aktivität fehl, wiederholt das Framework sie basierend auf der in Schritt 1 festgelegten Konfiguration.

Exponentielle Wiederholung mit der Klasse AsyncRetryingExecutor

Die RetryDecorator-Klasse bietet mehr Flexibilität bei der Konfiguration des Wiederholungsvorgangs als @ExponentialRetry, allerdings führt das Framework dennoch automatisch die Wiederholungen basierend auf der aktuellen Konfiguration des ExponentialRetryPolicy-Objekts aus. Ein flexiblerer Ansatz ist die Verwendung der AsyncRetryingExecutor-Klasse. Sie haben nicht nur die Möglichkeit, den Wiederholungsvorgang zur Laufzeit zu konfigurieren, sondern das Framework ruft zudem eine vom Benutzer implementierte AsyncRunnable.run-Methode zur Ausführung jeder Wiederholung auf, statt die Aktivität einfach auszuführen.

Das grundlegende Muster ist:

Der folgende Workflow zeigt, wie die AsyncRetryingExecutor-Klasse verwendet wird, um eine exponentielle Wiederholungsstrategie zu implementieren. Er verwendet dieselbe unreliableActivity-Aktivität wie der zuvor behandelte DecoratorRetryWorkflow-Workflow. Die Workflow-Schnittstelle wird in RetryWorkflow implementiert und enthält die Methode process, die den Eintrittspunkt des Workflows darstellt. Der Workflow-Worker wird in AsyncExecutorRetryWorkflowImpl wie folgt implementiert:

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

Der Workflow funktioniert folgendermaßen:

Weitere Informationen zur Verwendung der TryCatch-Klasse zur Fehlerbehandlung finden Sie unter AWS Flow Framework für Java-Ausnahmen.

Benutzerdefinierte Wiederholungsstrategie

Der flexibelste Ansatz zur Wiederholung fehlgeschlagener Aktivitäten ist eine benutzerdefinierte Strategie, bei der rekursiv eine asynchrone Methode aufgerufen wird, die den Wiederholungsversuch ausführt, ähnlich wie bei der Strategie. retry-until-success Statt die Aktivität einfach erneut auszuführen, implementieren Sie jedoch eine benutzerdefinierte Logik, die entscheidet, ob und wie jede Wiederholung ausgeführt werden soll. Das grundlegende Muster ist:

Der folgende Workflow zeigt, wie eine benutzerdefinierte Wiederholungsstrategie implementiert wird. Er verwendet dieselbe unreliableActivity-Aktivität wie der DecoratorRetryWorkflow- und AsyncExecutorRetryWorkflow-Workflow. Die Workflow-Schnittstelle wird in RetryWorkflow implementiert und enthält die Methode process, die den Eintrittspunkt des Workflows darstellt. Der Workflow-Worker wird in CustomLogicRetryWorkflowImpl wie folgt implementiert:

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

Der Workflow funktioniert folgendermaßen: