Hinweis zum Ende des Supports: Am 13. November 2025 AWS wird der Support für Amazon Elastic Transcoder eingestellt. Nach dem 13. November 2025 können Sie nicht mehr auf die Elastic Transcoder Transcoder-Konsole oder die Elastic Transcoder Transcoder-Ressourcen zugreifen.

Weitere Informationen zur Umstellung auf finden Sie in diesem AWS Elemental MediaConvert Blogbeitrag.

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.

Umgang mit Fehlern in Elastic Transcoder

Wenn Sie Anfragen an die Elastic Transcoder API senden und Antworten von dieser erhalten, können zwei Arten von API-Fehlern auftreten:

Für jeden API-Fehler gibt Elastic Transcoder die folgenden Werte zurück:

Eine Liste der Fehlercodes, die Elastic Transcoder bei Client- und Serverfehlern zurückgibt, finden Sie unterAPI-Fehlercodes (Client- und Server-Fehler).

Außerdem kann es zu folgenden Situationen bezüglich des Workloads Elastic Transcoder bezüglich des Workloads kann. Weitere Informationen finden Sie unter Fehler während der Auftragsverarbeitung.

API-Fehlercodes (Client- und Server-Fehler)

HTTP-Statuscodes geben an, ob ein Vorgang erfolgreich war.

Ein Antwortcode 200 gibt an, dass der Vorgang erfolgreich war. Andere Antwortcodes weisen entweder auf einen Client-Fehler (4xx) oder einen Server-Fehler (5xx) hin.

In der folgenden Tabelle finden Sie die von Elastic Transcoder Einige Fehler werden behoben, indem Sie ganz einfach die Anforderung wiederholen. Die Tabelle zeigt, welche Fehler wahrscheinlich durch Wiederholversuche behoben werden. Der Wert in der Spalte "Erneut versuchen" bedeutet:

Weitere Informationen zum Wiederholen von Anforderungen finden Sie unter Wiederholversuche bei Fehlern und exponentielles Backoff.

Beispielantwort auf einen Fehler

Die folgende HTTP-Antwort gibt an, dass für inputBucket ein Wert "null" zurückgegeben wurde, wobei es sich nicht um einen gültigen Wert handelt.

HTTP/1.1 400 Bad Request
x-amzn-RequestId: b0e91dc8-3807-11e2-83c6-5912bf8ad066
x-amzn-ErrorType: ValidationException
Content-Type: application/json
Content-Length: 124
Date: Mon, 26 Nov 2012 20:27:25 GMT

{"message":"1 validation error detected: Value null at 'inputBucket' failed to satisfy constraint: Member must not be null"}

Fehler während der Auftragsverarbeitung

Wenn Elastic Transcoder bei der Verarbeitung Ihres Jobs auf einen Fehler stößt, wird der Fehler auf zwei Arten gemeldet:

Fehlererfassung

Damit Ihre Anwendung reibungslos ausgeführt wird, müssen Sie Logik zum Erfassen und Behandeln von Fehlern integrieren. Eine übliche Vorgehensweise ist es, Ihre Anforderung in einem try-Block oder einer if-then-Anweisung zu implementieren.

Die AWS SDKs führen eigene Wiederholversuche und Fehlerprüfungen aus. Wenn bei der Verwendung eines der AWS SDKs ein Fehler auftritt, finden Sie im Fehlercode und der Beschreibung weitere Hinweise. Prüfen Sie auch den Request ID-Wert. DerRequest ID Wert kann bei der Behebung von Problemen mit der Unterstützung von Elastic Transcoder helfen.

Das folgende Beispiel verwendet das AWS SDK for Java, um ein Element innerhalb eines try-Blocks zu löschen, und nutzt einen catch-Block, um auf den Fehler zu reagieren. In diesem Fall warnt es, dass die Anfrage fehlgeschlagen ist. Das Beispiel verwendet die AmazonServiceException-Klasse, um Informationen über Fehler bei Dateivorgängen abzurufen, einschließlich der Request ID. Das Beispiel verwendet außerdem die AmazonClientException-Klasse, falls die Anforderungen aus anderen Gründen nicht erfolgreich ist.

try {
   DeleteJobRequest request = new DeleteJobRequest(jobId);
   DeleteJobResult result = ET.deleteJob(request);
   System.out.println("Result: " + result);
   // Get error information from the service while trying to run the operation	
   }  catch (AmazonServiceException ase) {
      System.err.println("Failed to delete job " + jobId);
      // Get specific error information
      System.out.println("Error Message:    " + ase.getMessage());
      System.out.println("HTTP Status Code: " + ase.getStatusCode());
      System.out.println("AWS Error Code:   " + ase.getErrorCode());
      System.out.println("Error Type:       " + ase.getErrorType());
      System.out.println("Request ID:       " + ase.getRequestId());
   // Get information in case the operation is not successful for other reasons	
   }  catch (AmazonClientException ace) {
      System.out.println("Caught an AmazonClientException, which means"+
      " the client encountered " +
      "an internal error while trying to " +
      "communicate with Elastic Transcoder, " +
      "such as not being able to access the network.");
      System.out.println("Error Message: " + ace.getMessage());
   }

Wiederholversuche bei Fehlern und exponentielles Backoff

Zahlreiche Komponenten im Netzwerk, wie z. B. DNS-Server, Switches und Load Balancer, können irgendwann im Lebenszyklus einer Anforderung Fehler generieren.

Die übliche Methode zum Umgang mit diesen Fehlermeldungen in einer vernetzten Umgebung besteht darin, Wiederholversuche in der Client-Anwendung zu implementieren. Diese Vorgehensweise erhöht die Zuverlässigkeit der Anwendung und senkt die Betriebskosten für die Entwickler.

Jedes AWS-SDK, das Elastic Transcoder unterstützt, implementiert eine automatische Wiederholungslogik. Beim AWS SDK for Java werden Anforderungen automatisch wiederholt. Sie können die Einstellungen für Wiederholversuche mit der ClientConfiguration-Klasse konfigurieren. Sie können beispielsweise in einigen Fällen die Wiederholversuchslogik deaktivieren, z. B für eine Webseite, die eine Anforderung mit minimaler Latenz und ohne Wiederholversuche versendet. Verwenden Sie die ClientConfiguration-Klasse und geben Sie einen Wert für maxErrorRetry von 0 ein, um die Wiederholversuche zu deaktivieren.

Wenn Sie kein AWS SDK verwenden, sollten ursprüngliche Anforderungen wiederholt werden, die Server-Fehler (5xx) erhalten. Client-Fehler (4xx, außer ThrottlingException oder ProvisionedThroughputExceededException) hingegen weisen darauf hin, dass direkt die Anforderung geändert werden muss, um das Problem zu beheben. Erst dann sollte sie wiederholt werden.

Zusätzlich zu einfachen Wiederholversuchen wird zur besseren Flusssteuerung die Verwendung eines exponentiellen Backoff empfohlen. Die Idee hinter dem exponentiellen Backoff ist, bei aufeinander folgenden Fehlermeldungen progressiv längere Wartezeiten zwischen den Wiederholversuchen zu verwenden. Sie könnten z. B. vor dem ersten Wiederholversuch eine Sekunde verstreichen lassen, vor dem zweiten Wiederholversuch vier Sekunden, vor dem dritten Wiederholversuch 16 Sekunden usw. Wenn die Anforderung jedoch nach einer Minute nicht erfolgreich war, liegt das Problem möglicherweise an einem festen Limit und nicht an der Anforderungsrate. Vielleicht haben Sie z. B. die maximale Anzahl zulässiger Pipelines erreicht. Grenzen Sie die maximale Anzahl von Wiederholversuchen bis zu etwa einer Minute ein.

Nachfolgend sehen Sie einen Workflow, der die Logik für Wiederholversuche zeigt. Die Workflow-Logik bestimmt zuerst, ob der Fehler ein Serverfehler (5xx) ist. Wenn es sich bei dem Fehler um einen Serverfehler handelt, wiederholt der Code die ursprüngliche Anforderung.

currentRetry = 0
DO
  set retry to false

  execute Elastic Transcoder request

  IF Exception.errorCode = ProvisionedThroughputExceededException
    set retry to true
  ELSE IF Exception.httpStatusCode = 500
    set retry to true
  ELSE IF Exception.httpStatusCode = 400
    set retry to false 
    fix client error (4xx)

  IF retry = true  
    wait for (2^currentRetry * 50) milliseconds
    currentRetry = currentRetry + 1

WHILE (retry = true AND currentRetry < MaxNumberOfRetries)  // limit retries