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.

Se vuelve a intentar en AWS SDK para Kotlin

Las llamadas devuelven Servicios de AWS ocasionalmente excepciones inesperadas. Algunos tipos de errores, como los errores transitorios o de limitación, pueden producirse correctamente si se vuelve a intentar realizar la llamada.

En esta página, se describe cómo AWS SDK para Kotlin gestiona los reintentos automáticamente y cómo personalizar el comportamiento de los reintentos para las aplicaciones.

Comprender el comportamiento de los reintentos

En las siguientes secciones se explica cómo el SDK determina cuándo reintentar las solicitudes y qué excepciones se consideran reintentables.

Configuración de reintentos predeterminada

De forma predeterminada, cada cliente de servicio se configura automáticamente con una estrategia de reintentos estándar. La configuración predeterminada intenta realizar una llamada que falla hasta tres veces (el intento inicial más dos reintentos). El retardo intermedio entre cada llamada se configura con un retardo exponencial y una fluctuación aleatoria para evitar tormentas de reintentos. Esta configuración funciona en la mayoría de los casos de uso, pero puede no ser adecuada en algunas circunstancias, como en los sistemas de alto rendimiento.

El SDK solo intenta volver a intentarlo cuando hay errores que se puedan volver a intentar. Algunos ejemplos de errores que se pueden volver a intentar son los tiempos de espera de los sockets, la limitación del lado del servicio, los fallos de bloqueo simultáneos o optimistas y los errores de servicio transitorios. Los parámetros faltantes o no válidos, los authentication/security errores y las excepciones de mala configuración no se consideran reintentables.

Puede personalizar la estrategia de reintentos estándar estableciendo el número máximo de intentos, los retrasos y los retrasos, así como la configuración del conjunto de fichas.

¿Qué excepciones se pueden volver a intentar?

AWS SDK para Kotlin Utiliza una política de reintentos preconfigurada que determina qué excepciones se pueden volver a intentar. La configuración del cliente de servicio tiene una retryPolicy propiedad que especifica la política que se aplica a los reintentos. Si no se especifica ningún valor personalizado, el valor predeterminado es AwsRetryPolicy.

Se determina que las siguientes excepciones se pueden volver a intentar mediante: AwsRetryPolicy

Se puede volver a intentar mediante código de error

Cualquiera ServiceException con uno de los siguientes valoressdkErrorMetadata.errorCode:

Se puede volver a intentar mediante el código de estado HTTP

Cualquiera ServiceException con uno de los siguientes valoressdkErrorMetadata.statusCode:

Se puede volver a intentar por tipo de error

Cualquiera ServiceException con uno de los siguientes valoressdkErrorMetadata.errorType:

Se puede volver a intentar mediante metadatos del SDK

En cualquier lugarSdkBaseException:

Para obtener una lista completa de las excepciones que puede introducir cada cliente de servicio, consulta la documentación de referencia de la API específica del servicio.

Comprueba si una excepción se puede volver a intentar

Para determinar si el SDK considera que una excepción se puede volver a intentar, comprueba la propiedad de las excepciones detectadas: isRetryable

try {
    dynamoDbClient.putItem {
        tableName = "MyTable"
        item = mapOf("id" to AttributeValue.S("123"))
    }
} catch (e: SdkBaseException) {
    println("Exception occurred: ${e.message}")
    
    if (e.sdkErrorMetadata.isRetryable) {
        println("This exception is retryable - SDK will automatically retry")
        println("If you're seeing this, retries may have been exhausted")
    } else {
        println("This exception is not retryable - fix the underlying issue")
        
        // Common non-retryable scenarios.
        when {
            e.message?.contains("ValidationException") == true -> 
                println("Check your request parameters")
            e.message?.contains("AccessDenied") == true -> 
                println("Check your IAM permissions")
            e.message?.contains("ResourceNotFound") == true -> 
                println("Verify the resource exists")
        }
    }
}

¿Qué excepciones llegan a tu código cuando los reintentos fallan?

Cuando el mecanismo de reintento del SDK no puede resolver un problema, se añaden excepciones al código de la aplicación. Comprender estos tipos de excepciones te ayuda a implementar una gestión de errores adecuada. Estas no son las excepciones que desencadenan las recuperaciones, sino que las gestiona internamente el SDK.

Su código detectará los siguientes tipos de excepciones cuando se agoten o deshabiliten los reintentos:

Usa el siguiente patrón para gestionar estas excepciones en tu aplicación:

try {
    s3Client.getObject { 
        bucket = "amzn-s3-demo-bucket"
        key = "my-key" 
    }
} catch (e: AwsServiceException) {
    // Service-side errors that persisted through all retries.
    println("Service error after retries: ${e.errorDetails?.errorCode} - ${e.message}")
    
    // Handle specific service errors that couldn't be resolved.
    if (e.errorDetails?.errorCode == "ServiceQuotaExceededException" || 
        e.errorDetails?.errorCode == "ThrottlingException") {
        println("Rate limiting persisted - consider longer delays or quota increase")
    }
} catch (e: ClientException) {
    // Client-side errors (persistent network issues, DNS resolution failures, etc.)
    println("Client error after retries: ${e.message}")
}

Personalización del comportamiento de los reintentos

En las siguientes secciones, se muestra cómo personalizar el comportamiento de reintentos del SDK para cada caso de uso específico.

Configura el número máximo de intentos

Puede personalizar el número máximo de intentos predeterminado (3) en el bloque retryStrategy DSL durante la construcción del cliente.

val dynamoDb = DynamoDbClient.fromEnvironment {
    retryStrategy {
        maxAttempts = 5
    }
}

Con el cliente del servicio DynamoDB mostrado en el fragmento anterior, el SDK intenta realizar llamadas a la API que fallan hasta cinco veces (el intento inicial más cuatro reintentos).

Para deshabilitar completamente los reintentos automáticos, establezca el número máximo de intentos en uno, como se muestra en el siguiente fragmento.

val dynamoDb = DynamoDbClient.fromEnvironment {
    retryStrategy {
        maxAttempts = 1  // The SDK makes no retries.
    }
}

Configure los retrasos y los retrasos

Si es necesario volver a intentarlo, la estrategia de reintento predeterminada espera antes de realizar el siguiente intento. El retraso del primer reintento es pequeño, pero aumenta exponencialmente en los reintentos posteriores. La cantidad máxima de retraso está limitada para que no aumente demasiado.

Por último, se aplica una fluctuación aleatoria a los retrasos entre todos los intentos. La fluctuación ayuda a mitigar el efecto de las grandes flotas, que pueden provocar tormentas que vuelvan a intentarlo. (Consulte esta entrada del blog de AWS arquitectura para obtener un análisis más profundo sobre el retroceso y la fluctuación exponenciales).

Los parámetros de retardo se pueden configurar en el bloque DSLdelayProvider.

val dynamoDb = DynamoDbClient.fromEnvironment {
    retryStrategy {
        delayProvider {
            initialDelay = 100.milliseconds
            maxBackoff = 5.seconds
        }
    }
}

Con la configuración que se muestra en el fragmento anterior, el cliente retrasa el primer intento hasta 100 milisegundos. El tiempo máximo entre un reintento es de 5 segundos.

Están disponibles los siguientes parámetros para los retrasos y el retardo del ajuste.

Configure el depósito de fichas de reintento

Puede modificar aún más el comportamiento de la estrategia de reintentos estándar ajustando la configuración predeterminada del depósito de fichas. El conjunto de fichas de reintentos ayuda a reducir los reintentos que tienen menos probabilidades de éxito o que pueden tardar más tiempo en resolverse, como los errores de tiempo de espera o de aceleración.

Cada reintento (incluido opcionalmente el intento inicial) reduce parte de la capacidad del depósito de fichas. La cantidad disminuida depende del tipo de intento. Por ejemplo, volver a intentar los errores transitorios puede resultar económico, pero volver a intentarlo cuando se agota el tiempo de espera o se reduce el tiempo de espera puede resultar más caro.

Si el intento se realiza correctamente, se devuelve la capacidad al depósito. El depósito no puede incrementarse más allá de su capacidad máxima ni reducirse por debajo de cero.

Según el valor de la useCircuitBreakerMode configuración, los intentos de reducir la capacidad por debajo de cero dan como resultado uno de los siguientes resultados:

Los parámetros del depósito de fichas se pueden configurar en el bloque tokenBucketDSL:

val dynamoDb = DynamoDbClient.fromEnvironment {
    retryStrategy {
        tokenBucket {
            maxCapacity = 100
            refillUnitsPerSecond = 2
        }
    }
}

Están disponibles los siguientes parámetros para ajustar el grupo de reintentos:

Para obtener información detallada sobre los tipos de excepciones que se producen durante los escenarios de reintento, incluidas las excepciones a los disyuntores, consulte. ¿Qué excepciones llegan a tu código cuando los reintentos fallan?

Configure los reintentos adaptativos

Como alternativa a la estrategia de reintentos estándar, la estrategia de reintentos adaptativa es un enfoque avanzado que busca la tasa de solicitudes ideal para minimizar los errores de limitación.

Los reintentos adaptables incluyen todas las características de los reintentos estándar. Añade un limitador de velocidad en el lado del cliente que mide la tasa de solicitudes restringidas en comparación con las solicitudes no restringidas. También limita el tráfico para intentar mantenerse dentro de un ancho de banda seguro, lo que idealmente no provoca errores de limitación.

La velocidad se adapta en tiempo real a los cambios en las condiciones del servicio y los patrones de tráfico y, en consecuencia, podría aumentar o disminuir la velocidad del tráfico. Lo que es más grave, el limitador de velocidad podría retrasar los intentos iniciales en situaciones de alto tráfico.

La estrategia de reintento adaptativo se selecciona proporcionando un parámetro adicional al método. retryStrategy Los parámetros del limitador de velocidad se pueden configurar en el bloque rateLimiterDSL.

val dynamoDb = DynamoDbClient.fromEnvironment {
    retryStrategy(AdaptiveRetryStrategy) {
        maxAttempts = 10
        rateLimiter {
            minFillRate = 1.0
            smoothing = 0.75
        }
    }
}