このスタックトレーススニペットを考える

原因：java.net.SocketException：ソフトウェアが接続を中止しました：
 java.net.SocketOutputStream.socketWrite0（Native Method）でのソケット書き込みエラー

私は次の質問に答えようとしました：

1. この例外をスローしているコードは何ですか？（JVM？/ Tomcat？/ My code？）
2. この例外がスローされる原因は何ですか？

＃1について：

SunのJVMソースにはこの正確なメッセージは含まれていませんが、「ソフトウェアによって接続が中止されました」というテキストが表示されると思います。ソケットの書き込みエラーは、SocketOutputStream。

private native void socketWrite0(FileDescriptor fd, byte[] b, int off,
                 int len) throws IOException;

＃2について

私の推測では、完全な応答を取得する前にクライアントが接続を終了したときに発生します（たとえば、要求を送信したが、完全な応答を取得する前に、閉じられた/終了した/オフラインになった）。

質問：

1. 上記の仮定は正しいですか（＃1および＃2）？
2. これは「サーバー側のネットワークエラーのため、クライアントに書き込むことができませんでした」という状況と区別できますか？それとも同じエラーメッセージが表示されますか？
3. そして最も重要なこと：上記について述べた公式文書（Sunなど）はありますか？

このスタックトレースがソケットクライアントの「障害」であることを証明する必要があります。サーバーがそれを回避するためにできることは何もありません。（例外のキャッチ、またはSun JVM以外のSocketOutputStreamの使用を除いて、どちらもクライアントが終了したという事実を実際には回避しません）

このエラーは、データの再送信が失敗した後にWinSockが確立された接続を閉じた場合など、ローカルネットワークシステムが接続を中止した場合に発生する可能性があります（受信側はデータストリームソケットで送信されたデータを確認しません）。

このMSDNの記事を参照してください。「ソフトウェアによる接続の中止」に関する情報も参照してください。

java.net.SocketException作成またはアクセスエラーが発生した場合にスローされるソケット（例えば、TCP）。これは通常、サーバーが接続を（適切に閉じずに）終了したため、完全な応答を取得する前に発生する可能性があります。ほとんどの場合、これはタイムアウトの問題（応答に時間がかかりすぎるか、サーバーが要求で過負荷になっているなど）、またはクライアントがSYNを送信したが、ACKを受信しなかった（接続終了の確認）のいずれかが原因です。 。タイムアウトの問題については、タイムアウト値を増やすことを検討できます。

ソケット例外には通常、問題に関する特定の詳細メッセージが付属しています。

詳細なメッセージの例：

• ソフトウェアによって接続が中止されました：recvが失敗しました。

  このエラーは、メッセージを送信しようとしたことを示し、接続はサーバーによって中止されました。データベースへの接続中にこれが発生した場合、これは互換性のないConnector / J JDBCドライバーの使用に関連している可能性があります。

  考えられる解決策：CLASSPATHに適切なライブラリー/ドライバーがあることを確認してください。

• ソフトウェアによって接続が中止されました：接続。

  これは、リモートへの接続に問題がある場合に発生する可能性があります。たとえば、ウイルスチェッカーがリモートメール要求を拒否したことが原因です。

  考えられる解決策：ウイルススキャンサービスで、接続の送信要求のポートがブロックされているかどうかを確認します。

• ソフトウェアにより接続が中止されました：ソケット書き込みエラー。

  考えられる解決策：正しいバイト長をストリームに書き込んでいることを確認してください。そのため、送信する内容を再確認してください。このスレッドを参照してください。

• ピアによる接続のリセット：ソケット書き込みエラー/ピアによる接続の中止：ソケット書き込みエラー

  アプリケーションは、キープアライブ接続がサーバー側でタイムアウトになったかどうかを確認しませんでした。

  考えられる解決策：接続から読み取る前に、HttpClientがnull以外であることを確認します。^E13222_01

• ピアによって接続がリセットされました。

  接続はピア（サーバー）によって終了されました。

• 接続がリセットされました。

  接続は、要求による要求が原因で、クライアントによって終了されたか、接続のサーバー側によって閉じられました。

  参照：java.net.SocketException：接続のリセットの原因は何ですか？

ワークステーション/ラップトップの企業ファイアウォールが邪魔になり、接続が切断されるときに、これをよく目にしました。

例えば。同じマシン上にサーバープロセスとクライアントプロセスがあります。サーバーはすべてのインターフェース（0.0.0.0）をlistenしており、クライアントはpublic / homeインターフェースへの接続を試みます（ループバックインターフェース127.0.0.1ではないことに注意してください）。

マシンのネットワークが切断されている（wifiがオフになっているなど）場合、接続が形成されます。マシンが企業ネットワークに（直接またはVPNで）接続されている場合、接続が形成されます。

ただし、マシンがパブリックwifi（またはホームネットワーク）に接続されている場合、ファイアウォールは接続を強制終了します。この状況では、クライアントをループバックインターフェイスに接続することは、ホーム/パブリックインターフェイスではなく、正常に機能します。

お役に立てれば。

どのコンポーネントに障害が発生したかを証明するには、wiresharkを使用してTCP / IP通信を監視し、ポートを実際に閉じているのが誰かを確認します。また、タイムアウトも関係する可能性があります。

Tomcatソースコードと JVMソースを確認しましたか？それはあなたにもっと助けを与えるかもしれません。

あなたの一般的な考え方は良いと思います。ConnectExceptionあなたが接続できなかったシナリオでは、私は期待します。上記はクライアント主導のように見えます。

単純なクライアントサーバープログラムを使用してこのエラーが発生する場合、入力ストリームまたは出力ストリームが閉じられていない（または早く閉じられている）ことが問題です。

私は同じ問題に直面していました。
一般に、この種のエラーは、クライアントが接続を閉じたために発生し、サーバーはそのクライアントでまだ書き込みを試みています。
したがって、サーバーがその出力ストリームを完了するまで、クライアントの接続が開いていることを確認してください。
そしてもう1つ、入力ストリームと出力ストリームを閉じるのを忘れないでください。

お役に立てれば。
それでも問題が解決しない場合は、ここで問題を詳しく説明してください。

このエラーは、SoapUIクライアントでSOAPサービスをテストしているときに発生しました。基本的に、非常に大きなメッセージ（> 500kb）を取得しようとしていて、SoapUIがタイムアウトによって接続を閉じました。

SoapUIで次の場所に移動します。

ファイル->設定-ソケットタイムアウト（ミリ秒）

...そして180000（3分）などの大きな値を入力すると、ファイルは実際には非常に大きいため、これは問題の完全な修正にはなりませんが、少なくとも応答はあります。

別のクライアントの閉じられた接続

私の場合、エラーは：

java.net.SocketException: Software caused connection abort: recv failed

H2データベースにアクセスするJavaアプリケーションのデバッグ中にEclipseで受信されました。エラーの原因は、最初にSQuirreLを使用してデータベースを開き、整合性を手動でチェックしたことです。フラグを使用して同じDB（つまりAUTO_SERVER=TRUE）への複数の接続を有効にしたので、JavaからDBへの接続に問題はありませんでした。

エラーは、しばらくすると-それは長いJavaプロセスです-SQuirreLを閉じてリソースを解放することを決めたときに表示されました。SQuirreLがDBサーバーインスタンスを「所有している」ものであり、SQuirreL接続でシャットダウンされたように見えます。

Javaアプリケーションを再起動しても、エラーは発生しませんでした。

設定

• Windows 7
• Eclipseケプラー
• SQuirreL 3.6
• org.h2.Driverバージョン1.4.192

私の場合、クライアントとサーバー側を開発しましたが、例外があります：

原因：引数のマーシャリングエラー。ネストされた例外は次のとおりです：java.net.SocketException：ソフトウェアが接続を中止しました：ソケット書き込みエラー

クライアントとサーバーのクラスが異なる場合。サーバーのクラス（インターフェイス）をクライアントにダウンロードしません。同じファイルをプロジェクトに追加します。しかし、パスはまったく同じでなければなりません。たとえば、サーバープロジェクトでは、いくつかのserviceInterfaceと実装を含むjava \ rmi \ servicesパッケージがあり、クライアントプロジェクトで同じパッケージを作成する必要があります。たとえば、java / rmi / server / servicesで変更すると、上記の例外が発生します。クライアントとサーバー間でインターフェースのバージョンが異なる場合も同じ例外（空の行が誤って追加された場合でも...バージョンを確認するためにrmiがクラスのハッシュのようなものを作成すると思います...わからない...もし可能なら助けて ...

私のサーバーは2日のパスでこの例外をスローしていましたが、次のコマンドで切断機能を移動することで解決しました。

outputStream.close();
inputStream.close();
Client.close();

リストスレッドの最後まで。それが誰かを助けるなら。

以下で説明する状況では、クライアント側がそのような例外をスローします。

サーバーはクライアント証明書を認証するように求められますが、クライアントは拡張キー使用法がクライアント認証をサポートしない証明書を提供するため、サーバーはクライアントの証明書を受け入れず、接続を閉じます。

sslクライアント側は、以下の状況（テスト済み）でこのような例外をスローします。

サーバーはクライアント証明書を認証するように求められますが、クライアントは拡張キー使用法がクライアント認証をサポートしない証明書を提供します。

残りのAPI呼び出しをモックしているときに、wireMockで同じ問題に直面していました。以前は、次のようにサーバーを定義していました。

WireMockServer wireMockServer = null;

ただし、次のように定義する必要があります。

@Rule 
public WireMockRule wireMockRule = new WireMockRule(8089);