翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# トラブルシューティングに関するよくある質問
AWS SDK for Kotlin アプリケーションで を使用すると、このトピックに記載されているいくつかの問題が発生する可能性があります。根本原因を特定し、エラーを解決するには、次の提案を参考にしてください。
## 「接続が閉じられた」問題を修正するにはどうすればよいですか?
次のいずれかのタイプなどの例外として、「接続が閉じられた」問題が発生する可能性があります。
+ `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)`
これらの例外は、SDK からサービスへの TCP 接続が予期せず閉じられたか、リセットされたことを示します。接続は、ホスト、 AWS サービス、または NAT ゲートウェイ、プロキシ、ロードバランサーなどの仲介者によって閉じられた可能性があります。
これらのタイプの例外は自動的に再試行されますが、ログ記録設定によっては SDK ログに表示される場合があります。例外がコードにスローされた場合、アクティブな再試行戦略が最大試行回数や再試行トークンバケットなど、設定された制限を使い果たしたことを示します。再試行戦略の詳細については、このガイドの[で再試行する AWS SDK for Kotlin](retries.md)「」セクションを参照してください。[最大試行回数に達する前に例外がスローされるのはなぜですか?](#ts-faq-exceptions-before-max) も参照してください。
### OkHttpEngine によるアイドル接続のモニタリング
を使用して`OkHttpEngine`いて、`IOException: unexpected end of stream on `例外が頻繁に発生する場合は、[アイドル状態の接続モニタリングを有効にすることを検討](http-client-config.md#http-idle-connection-monitoring)してください。この機能は、リモートサーバーがまだ接続プールにある接続を閉じているかどうかを検出するため、これらの例外の発生を減らすことができます。
## 最大試行回数に達する前に例外がスローされるのはなぜですか?
再試行が予想されたが、代わりにスローされた例外が表示される場合があります。このような状況では、次の手順が問題の解決に役立つ場合があります。
+ **例外が再試行可能であることを確認します。**例えば、不正な形式のサービスリクエスト、アクセス許可の欠如、存在しないリソースを示す例外など、一部の例外は再試行できません。SDK は、これらの種類の例外を自動的に再試行しません。再試行可能な例外を確認する方法については、「」を参照してください[例外が再試行可能かどうかを確認します。](retries.md#retries-check-exception-retryable)。
+ **例外がコードにスローされていることを確認します。**一部の例外はログメッセージに情報として表示されますが、実際にはコードにスローされません。例えば、スロットリングエラーなどの再試行可能な例外は、SDK が複数のbackoff-and-retryサイクルを自動的に実行するとログに記録される場合があります。SDK オペレーションの呼び出しは、設定された再試行設定で処理されなかった場合にのみ例外をスローします。
+ **設定した再試行設定を確認します。**再試行戦略と再試行ポリシーの詳細については、このガイドの[で再試行する AWS SDK for Kotlin](retries.md)「」セクションを参照してください。コードが想定した設定または自動デフォルトを使用していることを確認します。
+ **再試行設定の調整を検討してください。**前の項目を検証しても問題が解決しない場合は、再試行設定の調整を検討してください。
+ **最大試行回数を増やします。**デフォルトでは、 オペレーションの最大試行回数は 3 回です。これが十分ではなく、デフォルト設定で例外が発生している場合は、クライアント設定で `retryStrategy.maxAttempts`プロパティを増やすことを検討してください。詳細については「[最大試行回数を設定する](retries.md#retires-max-attempts)」を参照してください。
+ **遅延設定を増やします。**一部の例外は、基盤となる条件が解決される前に、あまりにも迅速に再試行される可能性があります。その場合は、クライアント設定で `retryStrategy.delayProvider.initialDelay`または `retryStrategy.delayProvider.maxBackoff`プロパティを増やすことを検討してください。詳細については「[遅延とバックオフを設定する](retries.md#retries-delays-backoff)」を参照してください。
+ **サーキットブレーカーモードを無効にします。**SDK は、デフォルトで各サービスクライアントのトークンのバケットを維持します。SDK がリクエストを試行し、再試行可能な例外で失敗すると、トークン数は減少し、リクエストが成功すると、トークン数は増加します。
デフォルトでは、このトークンバケットが残り 0 トークンに達すると、回路が壊れます。回路が切断されると、SDK は再試行を無効にし、最初の試行で失敗した現在および後続のリクエストは直ちに例外をスローします。SDK は、最初の試行が成功するとトークンバケットに十分な容量を返した後、再試行を再度有効にします。この動作は意図的なものであり、サービス停止やサービス復旧中の再試行ストームを防ぐように設計されています。
SDK が設定された最大試行回数まで再試行し続ける場合は、クライアント設定で `retryStrategy.tokenBucket.useCircuitBreakerMode`プロパティを false に設定して、サーキットブレーカーモードを無効にすることを検討してください。このプロパティを false に設定すると、SDK クライアントはトークンバケットが十分な容量に達するまで待機します。残りのトークンが 0 個ある場合、例外につながる可能性のある追加の再試行は中止しません。
## `NoSuchMethodError` または NoClassDefFoundError を修正するにはどうすればよいですか?
これらのエラーは、依存関係の欠落または競合によって最も一般的に発生します。詳細については「[依存関係の競合を解決するにはどうすればよいですか?](ts-faq-dep-conflict-resolution.md)」を参照してください。
### `NoClassDefFoundError` の が表示されます `okhttp3/coroutines/ExecuteAsyncKt`
これは、特に OkHttp の依存関係の問題を示します。詳細については「[アプリケーションでの OkHttp バージョンの競合の解決](ts-faq-dep-conflict-resolution.md#okhttp-dep-conflicts)」を参照してください。
# 依存関係の競合を解決するにはどうすればよいですか?
を使用する場合は AWS SDK for Kotlin、特定の AWS およびサードパーティーの依存関係が正しく動作する必要があります。これらの依存関係が実行時に欠落している、または予期しないバージョンがある場合、 `NoSuchMethodError`や などのエラーが表示されることがあります`NoClassDefFoundError`。これらの依存関係の問題は、通常 2 つのグループに分類されます。
+ SDK/Smithy 依存関係の競合
+ サードパーティーの依存関係の競合
Kotlin アプリケーションを構築するときは、Gradle を使用して依存関係を管理する可能性があります。SDK サービスクライアントへの依存関係をプロジェクトに追加すると、関連するすべての依存関係が自動的に含まれます。ただし、アプリケーションに他の依存関係がある場合、SDK で必要な依存関係と競合する可能性があります。例えば、SDK は、アプリケーションが使用する一般的な HTTP クライアントである OkHttp に依存しています。これらの競合を見つけるために、Gradle はプロジェクトの依存関係を一覧表示する便利なタスクを提供します。
```
./gradlew dependencies
```
依存関係の競合が発生した場合は、アクションを実行する必要がある場合があります。特定のバージョンの依存関係またはシャドウ依存関係をローカル名前空間に指定できます。Gradle 依存関係の解決は、*Gradle ユーザーマニュアル*の以下のセクションで説明する複雑なトピックです。
+ [ 依存関係の解決について ](https://docs.gradle.org/current/userguide/dependency_resolution.html)
+ [ 依存関係の制約と競合の解決 ](https://docs.gradle.org/current/userguide/dependency_constraints_conflicts.html)
+ [ 依存関係バージョンの調整 ](https://docs.gradle.org/current/userguide/dependency_version_alignment.html)
## プロジェクトの SDK と Smithy の依存関係の管理
SDK を使用する場合は、そのモジュールは通常、バージョン番号が一致する他の SDK モジュールに依存することに注意してください。たとえば、 `aws.sdk.kotlin:s3:1.2.3`は に依存し`ws.sdk.kotlin:aws-http:1.2.3`、 は に依存し`aws.sdk.kotlin:aws-core:1.2.3`ます。
SDK モジュールは、特定の Smithy モジュールバージョンも使用します。Smithy モジュールバージョンは SDK バージョン番号と同期しませんが、SDK の想定バージョンと一致する必要があります。たとえば、 `aws.sdk.kotlin:s3:1.2.3`は に依存し`aws.smithy.kotlin:serde:1.1.1`、 は に依存し`aws.smithy.kotlin:runtime-core:1.1.1`ます。
依存関係の競合を回避するには、すべての SDK 依存関係を一緒にアップグレードし、明示的な Smithy 依存関係に対して同じ操作を行います。[Gradle バージョンカタログ](setup-create-project-file.md)を使用してバージョンを同期させ、SDK と Smithy バージョン間のマッピングにおける推測を排除することを検討してください。
SDK/Smithy モジュールのマイナーバージョン更新には、[バージョニングポリシー](https://github.com/awslabs/aws-sdk-kotlin/blob/main/VERSIONING.md#versioning-policy)で説明されているように、重大な変更が含まれる場合があることに注意してください。マイナーバージョン間でアップグレードする場合は、変更ログを慎重に確認し、ランタイム動作を徹底的にテストしてください。
## アプリケーションでの OkHttp バージョンの競合の解決
[OkHttp](https://square.github.io/okhttp/) は、SDK が JVM でデフォルトで使用する一般的な HTTP エンジンです。アプリケーションには、別の OkHttp バージョンを取り込む他の依存関係やフレームワークが含まれる場合があります。これにより、 `okhttp/coroutines/ExecuteAsyncKt` や など、`okhttp3`名前空間内の`NoClassDefFoundError`クラスの が発生する可能性があります`okhttp3/ConnectionListener`。この場合、通常、新しいバージョンを選択して競合を解決する必要があります。これらの競合の原因を追跡しやすくするために、Gradle には便利なタスクが用意されています。以下を実行して、すべての依存関係を一覧表示できます。
```
./gradlew dependencies
```
たとえば、SDK が OkHttp に依存し`5.0.0-alpha.14`、Spring Boot などの別の依存関係が OkHttp に依存している場合は`4.12.0`、 を使用する必要があります`5.0.0-alpha.14 version`。これを行うには、Gradle の `constraints`ブロックを使用します。
```
dependencies {
constraints {
implementation("com.squareup.okhttp3:okhttp:4.12.0")
}
}
```
または、OkHttp 4.x を使用する必要がある場合、SDK は を提供します`OkHttp4Engine`。Gradle を設定してコード`OkHttp4Engine`で使用する方法については、 [ドキュメント](https://github.com/smithy-lang/smithy-kotlin/tree/main/runtime/protocol/http-client-engines/http-client-engine-okhttp4)を参照してください。