Aviso de fin de soporte: el 13 de noviembre de 2025, AWS dejaremos de ofrecer soporte a Amazon Elastic Transcoder. Después del 13 de noviembre de 2025, ya no podrás acceder a la consola de Elastic Transcoder ni a los recursos de Elastic Transcoder.

Para obtener más información sobre la transición a AWS Elemental MediaConvert, visite esta entrada de blog.

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Gestión de errores en Elastic Transcoder

Cuando se envían solicitudes a la API de Elastic Transcoder y se obtienen respuestas de ella, pueden producirse dos tipos de errores de API:

Para cada error de la API, Elastic Transcoder devuelve los siguientes valores:

Para obtener una lista de los códigos de error que Elastic Transcoder devuelve para los errores de cliente y servidor, consulte Códigos de error de la API (errores de cliente y de servidor).

Además, podría producirse otros errores mientras Elastic Transcoder procesa la tarea. Para obtener más información, consulte Errores durante el procesamiento de la tarea.

Códigos de error de la API (errores de cliente y de servidor)

Los códigos de estado HTTP indican si una operación se ejecuta correctamente o no.

Un código de respuesta 200 indica que la operación se ha realizado correctamente. Otros códigos de error indican un error de cliente (4xx) o de servidor (5xx).

En la siguiente tabla se muestran los errores devueltos por Elastic Transcoder. Algunos errores se resuelven con solo reintentar la misma solicitud. En la tabla se indica qué errores es probable que se resuelvan con reintentos sucesivos. Si el valor de la columna es Reintentar es:

Para obtener más información sobre el reintento de solicitudes, consulte Reintentos de error y retardo exponencial.

Ejemplo de respuesta de error

A continuación se muestra una respuesta HTTP que indica que el valor de inputBucket era “null” (nulo), que no es un valor válido.

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

Errores durante el procesamiento de la tarea

Siempre que Elastic Transcoder se encuentra con un error al procesar su tarea, lo notifica de dos formas:

Captura de errores

Para que la aplicación funcione sin problemas, es preciso integrar lógica que capture los errores y responda a ellos. Un enfoque habitual consiste en implementar la solicitud en un bloque try o una instrucción if-then.

Los AWS SDK llevan a cabo sus propios reintentos y comprobaciones de errores. Si se produce algún error al utilizar uno de los AWS SDK, deben aparecer su código y descripción. También debe aparecer un valor de Request ID. El valor de Request ID puede ayudarle a solucionar los problemas de compatibilidad con Elastic Transcoder.

En el siguiente ejemplo se usa AWS SDK para Java para eliminar un elemento dentro de un bloque try y usa un bloque catch para responder al error. En este caso, advierte de que se ha producido un error en la solicitud. En el ejemplo se usa la clase AmazonServiceException para recuperar información acerca de cualquier error de operación, incluido Request ID. En el ejemplo también se usa la clase AmazonClientException en caso de que la solicitud no se realice correctamente por otras razones.

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

Reintentos de error y retardo exponencial

Numerosos componentes de una red, como los servidores DNS, los conmutadores o los balanceadores de carga, entre otros, pueden generar errores en cualquier punto de la vida de una solicitud determinada.

La técnica habitual para abordar estas respuestas de error en un entorno de red consiste en implementar los reintentos en la aplicación cliente. Esta técnica aumenta la confiabilidad de la aplicación y reducen los costos operativos para el desarrollador.

Cada AWS SDK que admite Elastic Transcoder implementa una lógica de reintentos automática. AWS SDK para Java reintenta automáticamente las solicitudes y le permite configurar los ajustes de reintento mediante la clase ClientConfiguration. Por ejemplo, en algunos casos, como una página web que realiza una solicitud con la mínima latencia y sin reintentos, es posible que sea conveniente desactivar la lógica de reintento. Utilice la clase ClientConfiguration y proporcione un valor de maxErrorRetry de 0 para desactivar los reintentos.

Si no utiliza un SDK de AWS, debe reintentar las solicitudes originales que reciban errores de servidor (5xx). Sin embargo, los errores de cliente (4xx, salvo las excepciones ThrottlingException o ProvisionedThroughputExceededException) indican que es preciso revisar la solicitud en sí para corregir el problema antes de volver a intentarlo.

Además de los reintentos sencillos, recomendamos usar un algoritmo de retardo exponencial para mejorar el control de flujo. El retardo exponencial se basa en la idea de utilizar tiempos de espera progresivamente más largos entre reintentos para las respuestas a errores consecutivos. Por ejemplo, puede dejar que transcurra un segundo antes del primer reintento, cuatro antes del segundo, 16 segundos antes del tercero, y así sucesivamente. Sin embargo, si la solicitud no se ha llevado a cabo correctamente al cabo de un minuto, el problema podría radicar en un límite duro y no en la velocidad de solicitudes. Por ejemplo, es posible que se haya alcanzado el número máximo de canalizaciones permitidas. Establezca el número máximo de reintentos de modo que se detenga al cabo de un minuto.

A continuación, se incluye un flujo de trabajo que muestra la lógica de reintento. La lógica del flujo de trabajo, en primer lugar, determina si el error es un error de servidor (5xx). A continuación, si el error es un error de servidor, el código reintenta la solicitud original.

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