翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# トラブルシューティングに関するよくある質問
<a name="troubleshooting-faqs"></a>

 AWS SDK for Kotlin アプリケーションで を使用すると、このトピックに記載されているいくつかの問題が発生する可能性があります。根本原因を特定し、エラーを解決するには、次の提案を参考にしてください。

## 「接続が閉じられた」問題を修正するにはどうすればよいですか?
<a name="ts-faq-connection-closed"></a>

次のいずれかのタイプなどの例外として、「接続が閉じられた」問題が発生する可能性があります。
+ `IOException: unexpected end of stream on {{<URL>}}`
+ `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 によるアイドル接続のモニタリング
<a name="ts-faq-connection-closed-okhttp"></a>

を使用して`OkHttpEngine`いて、`IOException: unexpected end of stream on <URL>`例外が頻繁に発生する場合は、[アイドル状態の接続モニタリングを有効にすることを検討](http-client-config.md#http-idle-connection-monitoring)してください。この機能は、リモートサーバーがまだ接続プールにある接続を閉じているかどうかを検出するため、これらの例外の発生を減らすことができます。

## 最大試行回数に達する前に例外がスローされるのはなぜですか?
<a name="ts-faq-exceptions-before-max"></a>

再試行が予想されたが、代わりにスローされた例外が表示される場合があります。このような状況では、次の手順が問題の解決に役立つ場合があります。
+ **例外が再試行可能であることを確認します。**例えば、不正な形式のサービスリクエスト、アクセス許可の欠如、存在しないリソースを示す例外など、一部の例外は再試行できません。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 を修正するにはどうすればよいですか?
<a name="ts-faq-nusuchmethod"></a>

これらのエラーは、依存関係の欠落または競合によって最も一般的に発生します。詳細については「[依存関係の競合を解決するにはどうすればよいですか?](ts-faq-dep-conflict-resolution.md)」を参照してください。

### `NoClassDefFoundError` の が表示されます `okhttp3/coroutines/ExecuteAsyncKt`
<a name="ts-faq-nusuchmethod-okhttp"></a>

これは、特に OkHttp の依存関係の問題を示します。詳細については「[アプリケーションでの OkHttp バージョンの競合の解決](ts-faq-dep-conflict-resolution.md#okhttp-dep-conflicts)」を参照してください。