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.
# Solución de problemas FAQs
A medida que lo utilice AWS SDK para Kotlin en sus aplicaciones, es posible que encuentre algunos de los problemas enumerados en este tema. Utilice las siguientes sugerencias para ayudar a descubrir la causa raíz y resolver el error.
## ¿Cómo soluciono los problemas de «conexión cerrada»?
Es posible que se produzcan problemas de «conexión cerrada» como excepciones, como alguno de los siguientes tipos:
+ `IOException: unexpected end of stream on `
+ `EOFException: \n not found: limit=0`
+ `HttpException: AWS_ERROR_HTTP_CONNECTION_CLOSED: The connection has closed or is closing.; crtErrorCode=2058; HttpErrorCode(CONNECTION_CLOSED)`
Estas excepciones indican que una conexión TCP del SDK a un servicio se cerró o restableció inesperadamente. Es posible que el host, el AWS servicio o un intermediario, como una puerta de enlace NAT, un proxy o un balanceador de carga, hayan cerrado la conexión.
Estos tipos de excepciones se vuelven a intentar automáticamente, pero es posible que sigan apareciendo en los registros del SDK, según la configuración de registro. Si incluyes la excepción en tu código, esto indica que la estrategia de reintentos activa ha agotado los límites configurados, como el número máximo de intentos o el número de reintentos. Consulta la [Se vuelve a intentar en AWS SDK para Kotlin](retries.md) sección de esta guía para obtener más información sobre las estrategias de reintentos. Véase también [¿Por qué se lanzan las excepciones antes de alcanzar el número máximo de intentos?](#ts-faq-exceptions-before-max).
### Supervisión de conexiones inactivas con el OkHttpEngine
Si utilizas las `IOException: unexpected end of stream on ` excepciones `OkHttpEngine` y las encuentras con frecuencia, [considera habilitar la supervisión de las conexiones inactivas](http-client-config.md#http-idle-connection-monitoring). Esta función detecta si los servidores remotos tienen conexiones cerradas que aún se encuentran en el grupo de conexiones, lo que puede reducir la aparición de estas excepciones.
## ¿Por qué se lanzan las excepciones antes de alcanzar el número máximo de intentos?
A veces, es posible que veas excepciones que esperabas que se volvieran a intentar, pero que en su lugar se han lanzado. En estas situaciones, los siguientes pasos pueden ayudar a resolver el problema.
+ **Compruebe que la excepción se puede volver a intentar.** Algunas excepciones no se pueden volver a intentar, como las que indican una solicitud de servicio con un formato incorrecto, falta de permisos o recursos inexistentes, por ejemplo. El SDK no vuelve a intentar automáticamente este tipo de excepciones. Para obtener información sobre cómo comprobar si hay excepciones que se puedan volver a intentar, consulte. [Comprueba si una excepción se puede volver a intentar](retries.md#retries-check-exception-retryable)
+ **Compruebe que la excepción esté incluida en el código.** Algunas excepciones aparecen en los mensajes de registro como información, pero en realidad no se incluyen en el código. Por ejemplo, las excepciones que se pueden volver a intentar, como los errores de limitación, pueden registrarse, ya que el SDK funciona automáticamente durante varios ciclos. backoff-and-retry La invocación de una operación del SDK genera una excepción solo si no se ha gestionado con los ajustes de reintento configurados.
+ **Verifica los ajustes de reintento configurados.** Consulte la [Se vuelve a intentar en AWS SDK para Kotlin](retries.md) sección de esta guía para obtener más información sobre las estrategias y políticas de reintentos. Asegúrese de que el código utilice la configuración esperada o los valores predeterminados automáticos.
+ **Considera la posibilidad de ajustar la configuración de reintentos.** Tras comprobar los elementos anteriores, pero el problema no se haya resuelto, podría plantearse ajustar la configuración de los reintentos.
+ **Aumente el número máximo de intentos.** De forma predeterminada, el número máximo de intentos de una operación es 3. Si considera que esto no es suficiente y se siguen produciendo excepciones con la configuración predeterminada, considere la posibilidad de aumentar la `retryStrategy.maxAttempts` propiedad en la configuración del cliente. Para obtener más información, consulte [Configura el número máximo de intentos](retries.md#retires-max-attempts).
+ **Aumente la configuración de retardo.** Es posible que algunas excepciones se vuelvan a intentar con demasiada rapidez antes de que la afección subyacente haya tenido la oportunidad de resolverse. Si sospecha que es así, considere la posibilidad de aumentar las `retryStrategy.delayProvider.maxBackoff` propiedades `retryStrategy.delayProvider.initialDelay` o en la configuración de su cliente. Para obtener más información, consulte [Configure los retrasos y los retrasos](retries.md#retries-delays-backoff).
+ **Desactive el modo de disyuntor.** De forma predeterminada, el SDK mantiene un conjunto de fichas para cada cliente de servicio. Cuando el SDK intenta realizar una solicitud y se produce un error con una excepción que se puede volver a intentar, el recuento de fichas disminuye; cuando la solicitud es correcta, el recuento de fichas aumenta.
De forma predeterminada, si este depósito de fichas alcanza los 0 fichas restantes, el circuito se interrumpe. Cuando se interrumpe el circuito, el SDK deshabilita los reintentos y cualquier solicitud actual o posterior que falle en el primer intento genera inmediatamente una excepción. El SDK vuelve a habilitar los reintentos después de que los intentos iniciales exitosos devuelvan suficiente capacidad al depósito de fichas. Este comportamiento es intencional y está diseñado para evitar una gran cantidad de reintentos durante las interrupciones del servicio y la recuperación del servicio.
Si prefiere que el SDK siga reintentándolo hasta alcanzar el máximo de intentos configurados, considere la posibilidad de deshabilitar el modo de disyuntor estableciendo la `retryStrategy.tokenBucket.useCircuitBreakerMode` propiedad en false en la configuración de su cliente. Con esta propiedad establecida en false, el cliente del SDK espera a que el depósito de fichas alcance la capacidad suficiente en lugar de abandonar los reintentos posteriores, lo que podría provocar una excepción cuando queden 0 fichas.
## ¿Cómo puedo corregir `NoSuchMethodError` o? NoClassDefFoundError
Por lo general, estos errores se deben a dependencias faltantes o conflictivas. Para obtener más información, consulte [¿Cómo resuelvo los conflictos de dependencia?](ts-faq-dep-conflict-resolution.md).
### Veo un formulario `NoClassDefFoundError` `okhttp3/coroutines/ExecuteAsyncKt`
Esto indica un problema de dependencia OkHttp específicamente. Para obtener más información, consulte [Resolver conflictos de OkHttp versiones en la aplicación](ts-faq-dep-conflict-resolution.md#okhttp-dep-conflicts).
# ¿Cómo resuelvo los conflictos de dependencia?
Cuando lo usa AWS SDK para Kotlin, necesita dependencias determinadas AWS y de terceros para funcionar correctamente. Si faltan estas dependencias o aparecen versiones inesperadas en tiempo de ejecución, es posible que veas errores como `NoSuchMethodError` o. `NoClassDefFoundError` Estos problemas de dependencia suelen clasificarse en dos grupos:
+ Conflictos de dependencia entre SDK/Smithy
+ Conflictos de dependencia de terceros
Cuando compiles tu aplicación de Kotlin, es probable que utilices Gradle para administrar las dependencias. Si agregas una dependencia de un cliente de servicio del SDK a tu proyecto, se incluyen automáticamente todas las dependencias relacionadas necesarias. Sin embargo, si tu aplicación tiene otras dependencias, es posible que entren en conflicto con las que requiere el SDK. Por ejemplo, el SDK se basa en OkHttp un popular cliente HTTP que también podría utilizar tu aplicación. Para ayudarte a detectar estos conflictos, Gradle ofrece una práctica tarea en la que se enumeran las dependencias de tu proyecto:
```
./gradlew dependencies
```
Cuando te encuentres con conflictos de dependencia, es posible que tengas que tomar medidas. Puedes especificar una versión concreta de una dependencia o ocultar dependencias en un espacio de nombres local. *La resolución de dependencias de Gradle es un tema complejo que se analiza en las siguientes secciones del manual del usuario de Gradle:*
+ [Entender la resolución de dependencias](https://docs.gradle.org/current/userguide/dependency_resolution.html)
+ [Restricciones de dependencia y resolución de conflictos](https://docs.gradle.org/current/userguide/dependency_constraints_conflicts.html)
+ [Alineación de las versiones de dependencia](https://docs.gradle.org/current/userguide/dependency_version_alignment.html)
## Administrar las dependencias del SDK y Smithy en tu proyecto
Cuando utilices el SDK, ten en cuenta que sus módulos suelen depender de otros módulos del SDK con números de versión coincidentes. Por ejemplo, `aws.sdk.kotlin:s3:1.2.3` depende de`ws.sdk.kotlin:aws-http:1.2.3`, que depende de`aws.sdk.kotlin:aws-core:1.2.3`, y así sucesivamente.
Los módulos del SDK también utilizan versiones específicas del módulo Smithy. Si bien las versiones de los módulos de Smithy no se sincronizan con los números de versión del SDK, deben coincidir con la versión prevista del SDK. Por ejemplo, `aws.sdk.kotlin:s3:1.2.3` puede depender de`aws.smithy.kotlin:serde:1.1.1`, de qué depende`aws.smithy.kotlin:runtime-core:1.1.1`, etc.
Para evitar conflictos de dependencias, actualiza todas las dependencias del SDK a la vez y haz lo mismo con cualquier dependencia explícita de Smithy. Considera la posibilidad de usar nuestro [catálogo de versiones de Gradle](setup-create-project-file.md) para mantener las versiones sincronizadas y eliminar las conjeturas a la hora de mapear entre las versiones del SDK y de Smithy.
[Recuerda que las actualizaciones menores de las versiones de SDK/Smithy los módulos pueden incluir cambios importantes, tal y como se describe en nuestra política de control de versiones.](https://github.com/awslabs/aws-sdk-kotlin/blob/main/VERSIONING.md#versioning-policy) Al actualizar entre versiones secundarias, revise detenidamente los registros de cambios y compruebe minuciosamente el comportamiento en tiempo de ejecución.
## Resolver conflictos de OkHttp versiones en la aplicación
[OkHttp](https://square.github.io/okhttp/)es un popular motor HTTP que el SDK utiliza de forma predeterminada en la JVM. La aplicación puede incluir otras dependencias o marcos que incluyan una versión diferente OkHttp . Esto puede provocar que aparezcan `NoClassDefFoundError` clases en el espacio de `okhttp3` nombres, como o. `okhttp/coroutines/ExecuteAsyncKt` `okhttp3/ConnectionListener` Cuando esto sucede, por lo general, debe elegir la versión más reciente para resolver los conflictos. Para ayudarte a rastrear las fuentes de estos conflictos, Gradle ofrece una tarea útil. Para hacer una lista de todas las dependencias, ejecuta lo siguiente:
```
./gradlew dependencies
```
Por ejemplo, si el SDK depende OkHttp `5.0.0-alpha.14` de otra dependencia, como Spring Boot OkHttp `4.12.0`, entonces debes usar el`5.0.0-alpha.14 version`. Puedes hacerlo con un `constraints` bloque en Gradle:
```
dependencies {
constraints {
implementation("com.squareup.okhttp3:okhttp:4.12.0")
}
}
```
Como alternativa, si debes usar la versión OkHttp 4.x, el SDK proporciona una. `OkHttp4Engine` Consulta la [documentación](https://github.com/smithy-lang/smithy-kotlin/tree/main/runtime/protocol/http-client-engines/http-client-engine-okhttp4) para obtener información sobre cómo configurar Gradle y usarlo `OkHttp4Engine` en tu código.