Economize custos e obtenha mais recursos com AWS Elemental MediaConvert

MediaConvert é um novo serviço de transcodificação de vídeo baseado em arquivos que fornece um conjunto abrangente de recursos avançados de transcodificação, com tarifas sob demanda a partir de 0,0075 USD por minuto. Leia mais.

Já usa o Amazon Elastic Transcoder? É simples migrar para o. MediaConvert Para obter mais informações, consulte esta visão geral, que inclui informações valiosas sobre o processo de migração e links para recursos adicionais.

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Tratamento de erros no Elastic Transcoder

Quando você envia solicitações e obtém respostas da API do Elastic Transcoder, podem ocorrer dois tipos de erro de API:

Para cada erro de API, o Elastic Transcoder retorna os seguintes valores:

Para obter uma lista de códigos de erro que o Elastic Transcoder retorna para clientes e servidores, consulte Códigos de erro de API (erros de cliente e servidor).

Além disso, você pode encontrar erros enquanto o Elastic Transcoder está processando seu trabalho. Para obter mais informações, consulte Erros durante o processamento do trabalho.

Códigos de erro de API (erros de cliente e servidor)

Os códigos de status HTTP indicam se uma operação foi ou não bem-sucedida.

Um código de resposta de 200 indica que a operação teve êxito. Outros códigos de erro indicam um erro de cliente (4xx) ou um erro de servidor (5xx).

A tabela a seguir relaciona erros retornados pelo Elastic Transcoder. Alguns erros são resolvidos simplesmente tentando enviar novamente a mesma solicitação. A tabela indica quais erros tendem a ser solucionados com novas tentativas sucessivas. Se o valor da coluna Tentar novamente:

Para mais informações sobre enviar novamente uma mesma solicitação, consulte Repetições de erro e recuo exponencial.

Resposta de erro de exemplo

A seguir é apresentada uma resposta HTTP que indica que o valor para inputBucket era nulo, e nulo não é um 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"}

Erros durante o processamento do trabalho

Quando o Elastic Transcoder encontra um erro ao processar seu trabalho, ele relata o erro de duas formas:

Identificação de erros

Para que seu aplicativo seja executado consistentemente, você precisa criar uma lógica para identificar erros e responder. Uma postura comum é implementar sua solicitação em um bloco try ou em uma declaração if-then.

Os SDKs da AWS realizam por conta própria novas tentativas e verificação de erros. Se você encontrar um erro ao usar um dos SDKs da AWS, provavelmente verá o código de erro e a descrição. Provavelmente você verá também o valor Request ID. O valor Request ID pode ajudar a resolver problemas junto ao suporte do Elastic Transcoder.

O exemplo a seguir usa o AWS SDK para Java para excluir um item em um bloco try e usa um bloco catch para responder ao erro. Nesse caso, ele informa que a solicitação falhou. O exemplo usa a classe AmazonServiceException para recuperar informações sobre quaisquer erros de operação, incluindo o Request ID. O exemplo também usa a classe AmazonClientException caso a solicitação não seja bem-sucedida por outros motivos.

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

Repetições de erro e recuo exponencial

Vários componentes em uma rede, como servidores DNS, switches, balanceadores de carga e outros, podem gerar erros em qualquer lugar do ciclo de vida de determinada solicitação.

A técnica usual para lidar com essas respostas de erro em um ambiente de rede é implementar novas tentativas no aplicativo cliente. Essa técnica aumenta a confiabilidade do aplicativo e reduz os custos operacionais para o desenvolvedor.

Todo AWS SDK compatível com o Elastic Transcoder implementa a lógica de novas tentativas automáticas. O AWS SDK para Java tentará realizar novas tentativas de solicitação automaticamente. Você pode definir as configurações de novas tentativas usando a classe ClientConfiguration. Por exemplo, em alguns casos, como uma página web que faz uma solicitação com latência mínima sem novas tentativas, você pode querer desativar a lógica de novas tentativas. Use a classe ClientConfiguration e forneça um valor maxErrorRetry de 0 para desativar as novas tentativas.

Se não estiver usando um SDK da AWS;, você deve tentar novamente as solicitações originais que recebem erros do servidor (5xx). No entanto, erros de cliente (4xx, diferente de ThrottlingException ou ProvisionedThroughputExceededException) indicam que você precisa revisar a solicitação para corrigir o problema antes de tentar novamente.

Além de novas tentativas simples, é recomendável usar um algoritmo de recuo exponencial para um melhor controle de fluxo. A ideia por trás do backoff exponencial é usar esperas progressivamente mais longas entre as novas tentativas para respostas de erro consecutivas. Por exemplo, você pode permitir um lapso de 1 segundo antes da primeira nova tentativa, 4 segundos antes da segunda nova tentativa, 16 segundos antes da terceira nova tentativa, e assim por diante. Contudo, se a solicitação não tiver êxito após um minuto, o problema talvez seja um limite fixo e não a taxa de solicitação. Por exemplo, você pode ter atingido o número máximo permitido de pipelines. Defina um tempo de interrupção de cerca de um minuto para o número máximo de novas tentativas.

Veja a seguir um fluxo de trabalho mostrando a lógica de novas tentativas. A lógica de fluxo de trabalho primeiro determina se o erro é um erro de servidor (5xx). Em seguida, se o erro for um erro de servidor, o código repetirá a solicitação 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