Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Résolution des problèmes FAQs
Lorsque vous l'utilisez AWS SDK pour Kotlin dans vos applications, vous pouvez rencontrer certains des problèmes répertoriés dans cette rubrique. Utilisez les suggestions suivantes pour découvrir la cause première et résoudre l'erreur.
## Comment résoudre les problèmes de « fermeture de la connexion » ?
Vous pouvez rencontrer des problèmes de « fermeture de connexion » en tant qu'exceptions telles que l'un des types suivants :
+ `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)`
Ces exceptions indiquent qu'une connexion TCP entre le SDK et un service a été fermée ou réinitialisée de façon inattendue. La connexion a peut-être été fermée par votre hôte, le AWS service ou un intermédiaire tel qu'une passerelle NAT, un proxy ou un équilibreur de charge.
Ces types d'exceptions sont automatiquement réessayés mais peuvent toujours apparaître dans les journaux du SDK, en fonction de votre configuration de journalisation. Si l'exception est introduite dans votre code, cela indique que la stratégie de nouvelle tentative active a épuisé ses limites configurées, telles que le nombre maximum de tentatives ou le bucket de jetons de nouvelles tentatives. Consultez la [Réessaie dans le AWS SDK pour Kotlin](retries.md) section de ce guide pour plus d'informations sur les stratégies de nouvelle tentative. Consultez également [Pourquoi des exceptions sont-elles émises avant que le nombre maximum de tentatives n'ait été atteint ?](#ts-faq-exceptions-before-max).
### Surveillance des connexions inactives avec OkHttpEngine
Si vous utilisez le `OkHttpEngine` et que vous rencontrez fréquemment `IOException: unexpected end of stream on ` des exceptions, [pensez à activer la surveillance des connexions inactives](http-client-config.md#http-idle-connection-monitoring). Cette fonctionnalité détecte lorsque des serveurs distants ont fermé des connexions qui se trouvent toujours dans le pool de connexions, ce qui peut réduire le nombre de ces exceptions.
## Pourquoi des exceptions sont-elles émises avant que le nombre maximum de tentatives n'ait été atteint ?
Parfois, vous pouvez voir des exceptions que vous vous attendiez à une nouvelle tentative, mais qui ont été rejetées à la place. Dans ces situations, les étapes suivantes peuvent vous aider à résoudre le problème.
+ **Vérifiez que l'exception peut être réessayée.** Certaines exceptions ne sont pas réessayables, comme celles qui indiquent une demande de service mal formée, un manque d'autorisations ou l'inexistence de ressources, par exemple. Le SDK ne réessaie pas automatiquement ce type d'exceptions. Pour plus d'informations sur la façon de vérifier les exceptions réessayables, consultez. [Vérifiez si une exception est réessayable](retries.md#retries-check-exception-retryable)
+ **Vérifiez que l'exception est introduite dans votre code.** Certaines exceptions apparaissent dans les messages du journal sous forme d'informations mais ne sont pas réellement intégrées à votre code. Par exemple, les exceptions réessayables, telles que les erreurs de limitation, peuvent être enregistrées car le SDK fonctionne automatiquement sur plusieurs cycles. backoff-and-retry L'invocation d'une opération du SDK génère une exception uniquement si elle n'a pas été gérée par les paramètres de nouvelle tentative configurés.
+ **Vérifiez les paramètres de nouvelle tentative que vous avez configurés.** Consultez la [Réessaie dans le AWS SDK pour Kotlin](retries.md) section de ce guide pour plus d'informations sur les stratégies de nouvelle tentative et les politiques relatives aux nouvelles tentatives. Assurez-vous que votre code utilise les paramètres que vous attendez ou les valeurs par défaut automatiques.
+ **Pensez à ajuster vos paramètres de nouvelle tentative.** Une fois que vous avez vérifié les éléments précédents, mais que le problème n'est pas résolu, vous pouvez envisager de modifier les paramètres de nouvelle tentative.
+ **Augmentez le nombre maximum de tentatives.** Par défaut, le nombre maximum de tentatives pour une opération est de 3. Si vous trouvez que cela ne suffit pas et que des exceptions se produisent toujours avec le paramètre par défaut, envisagez d'augmenter la `retryStrategy.maxAttempts` propriété dans la configuration de votre client. Pour plus d’informations, consultez [Configurer le nombre maximal de tentatives](retries.md#retires-max-attempts).
+ **Augmentez les paramètres de délai.** Certaines exceptions peuvent être réessayées trop rapidement avant que la condition sous-jacente n'ait eu l'occasion de se résoudre. Si vous pensez que c'est le cas, envisagez d'augmenter les `retryStrategy.delayProvider.maxBackoff` propriétés `retryStrategy.delayProvider.initialDelay` or dans la configuration de votre client. Pour plus d’informations, consultez [Configurer les délais et les retards](retries.md#retries-delays-backoff).
+ **Désactive le mode disjoncteur.** Le SDK gère par défaut un paquet de jetons pour chaque client de service. Lorsque le SDK tente une requête et qu'elle échoue avec une exception réessayable, le nombre de jetons est décrémenté ; lorsque la demande aboutit, le nombre de jetons est incrémenté.
Par défaut, si ce paquet de jetons atteint 0 jetons restants, le circuit est interrompu. Une fois le circuit interrompu, le SDK désactive les nouvelles tentatives et toutes les demandes en cours et suivantes qui échouent à la première tentative génèrent immédiatement une exception. Le SDK réactive les tentatives une fois que les premières tentatives réussies ont renvoyé suffisamment de capacité au bucket de jetons. Ce comportement est intentionnel et conçu pour éviter les tempêtes de nouvelles tentatives en cas de panne de service ou de rétablissement du service.
Si vous préférez que le SDK continue de réessayer jusqu'au nombre maximum de tentatives configurées, envisagez de désactiver le mode disjoncteur en définissant la `retryStrategy.tokenBucket.useCircuitBreakerMode` propriété sur false dans la configuration de votre client. Lorsque cette propriété est définie sur false, le client du SDK attend que le bucket de jetons atteigne une capacité suffisante plutôt que d'abandonner toute nouvelle tentative susceptible de provoquer une exception lorsqu'il ne reste aucun jeton.
## Comment puis-je réparer `NoSuchMethodError` ou NoClassDefFoundError ?
Ces erreurs sont le plus souvent causées par des dépendances manquantes ou conflictuelles. Pour plus d’informations, consultez [Comment résoudre les conflits de dépendance ?](ts-faq-dep-conflict-resolution.md).
### Je vois un `NoClassDefFoundError` pour `okhttp3/coroutines/ExecuteAsyncKt`
Cela indique un problème de dépendance pour OkHttp spécifiquement. Pour plus d’informations, consultez [Résolution des conflits de OkHttp version dans votre application](ts-faq-dep-conflict-resolution.md#okhttp-dep-conflicts).
# Comment résoudre les conflits de dépendance ?
Lorsque vous utilisez le AWS SDK pour Kotlin, il a besoin de certaines dépendances AWS et de dépendances tierces pour fonctionner correctement. Si ces dépendances sont absentes ou s'il s'agit de versions inattendues au moment de l'exécution, des erreurs telles que `NoSuchMethodError` ou peuvent s'afficher`NoClassDefFoundError`. Ces problèmes de dépendance se répartissent généralement en deux groupes :
+ Conflits de dépendance entre SDK/Smithy
+ Conflits liés à la dépendance
Lorsque vous créez votre application Kotlin, vous utiliserez probablement Gradle pour gérer les dépendances. L'ajout d'une dépendance à un client de service SDK à votre projet inclut automatiquement toutes les dépendances connexes nécessaires. Toutefois, si votre application possède d'autres dépendances, elles peuvent entrer en conflit avec celles requises par le SDK. Par exemple, le SDK s'appuie sur OkHttp un client HTTP populaire que votre application peut également utiliser. Pour vous aider à détecter ces conflits, Gradle propose une tâche pratique qui répertorie les dépendances de votre projet :
```
./gradlew dependencies
```
Lorsque vous rencontrez des conflits de dépendance, vous devrez peut-être prendre des mesures. Vous pouvez soit spécifier une version particulière d'une dépendance, soit masquer les dépendances dans un espace de noms local. La résolution des dépendances de Gradle est un sujet complexe qui est abordé dans les sections suivantes du manuel d'*utilisation de Gradle* :
+ [Comprendre la résolution des dépendances](https://docs.gradle.org/current/userguide/dependency_resolution.html)
+ [Contraintes de dépendance et résolution des conflits](https://docs.gradle.org/current/userguide/dependency_constraints_conflicts.html)
+ [Alignement des versions de dépendance](https://docs.gradle.org/current/userguide/dependency_version_alignment.html)
## Gestion des dépendances du SDK et de Smithy dans votre projet
Lorsque vous utilisez le SDK, gardez à l'esprit que ses modules dépendent généralement d'autres modules SDK dont les numéros de version correspondent. Par exemple, `aws.sdk.kotlin:s3:1.2.3` dépend de a`ws.sdk.kotlin:aws-http:1.2.3`, qui dépend de`aws.sdk.kotlin:aws-core:1.2.3`, et ainsi de suite.
Les modules du SDK utilisent également des versions spécifiques des modules Smithy. Bien que les versions du module Smithy ne soient pas synchronisées avec les numéros de version du SDK, elles doivent correspondre à la version attendue du SDK. Par exemple, `aws.sdk.kotlin:s3:1.2.3` peut dépendre de`aws.smithy.kotlin:serde:1.1.1`, qui dépend de`aws.smithy.kotlin:runtime-core:1.1.1`, etc.
Pour éviter les conflits de dépendances, mettez à niveau toutes les dépendances de votre SDK ensemble, et faites de même pour toutes les dépendances explicites de Smithy. Envisagez d'utiliser notre [catalogue de versions Gradle](setup-create-project-file.md) pour synchroniser les versions et éliminer les incertitudes lors du mappage entre les versions du SDK et de Smithy.
N'oubliez pas que les mises à jour mineures SDK/Smithy des modules peuvent inclure des modifications majeures, comme indiqué dans notre [politique de gestion des versions](https://github.com/awslabs/aws-sdk-kotlin/blob/main/VERSIONING.md#versioning-policy). Lorsque vous effectuez une mise à niveau entre des versions mineures, examinez attentivement les journaux des modifications et testez soigneusement le comportement d'exécution.
## Résolution des conflits de OkHttp version dans votre application
[OkHttp](https://square.github.io/okhttp/)est un moteur HTTP populaire que le SDK utilise par défaut sur JVM. Votre application peut inclure d'autres dépendances ou frameworks qui introduisent une OkHttp version différente. Cela peut provoquer un `NoClassDefFoundError` for dans l'espace de `okhttp3` noms, tel que `okhttp/coroutines/ExecuteAsyncKt` ou`okhttp3/ConnectionListener`. Dans ce cas, vous devez généralement choisir la version la plus récente pour résoudre les conflits. Pour vous aider à retracer les sources de ces conflits, Gradle propose une tâche utile. Vous pouvez répertorier toutes les dépendances en exécutant :
```
./gradlew dependencies
```
Par exemple, si le SDK dépend de OkHttp `5.0.0-alpha.14` et qu'une autre dépendance telle que Spring Boot en dépend OkHttp `4.12.0`, vous devez utiliser le`5.0.0-alpha.14 version`. Vous pouvez le faire avec un `constraints` bloc dans Gradle :
```
dependencies {
constraints {
implementation("com.squareup.okhttp3:okhttp:4.12.0")
}
}
```
Sinon, si vous devez utiliser OkHttp 4.x, le SDK fournit un. `OkHttp4Engine` Consultez la [documentation](https://github.com/smithy-lang/smithy-kotlin/tree/main/runtime/protocol/http-client-engines/http-client-engine-okhttp4) pour savoir comment configurer Gradle et l'utiliser `OkHttp4Engine` dans votre code.