java.net.SocketException：壊れたパイプを修正する方法

私はapache commons http clientを使用して、postメソッドを使用してurlを呼び出し、パラメーターを送信していますが、まれに以下のエラーがスローされます。

java.net.SocketException: Broken pipe
        at java.net.SocketOutputStream.socketWrite0(Native Method)
        at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
        at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
        at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105)
        at java.io.FilterOutputStream.write(FilterOutputStream.java:80)
        at org.apache.commons.httpclient.methods.ByteArrayRequestEntity.writeRequest(ByteArrayRequestEntity.java:90)
        at org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:499)
        at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114)
        at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096)
        at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)

誰かがこの例外の原因とそれをデバッグする方法を提案できますか？

これは次の原因で発生します：

• ほとんどの場合、もう一方の端がすでに接続を閉じているときに接続に書き込みます。
• あまり一般的ではありませんが、ピアは自分の側ですでに保留中のすべてのデータを読み取らずに接続を閉じます。

したがって、どちらの場合でも、アプリケーションプロトコルの定義や実装が不十分です。

ここでは説明しませんが、ピアが接続を適切に閉じるのではなく、意図的にリセットするために意図的なアクションをとる3番目の理由があります。

私たちのケースでは、アプリサーバーで負荷テストを実行しているときにこれを経験しました。この問題は、JVMが不足していたため、JVMにメモリを追加する必要があることがわかりました。これで問題は解決しました。

これらのエラーが発生した場合は、JVMで使用可能なメモリを増やすか、メモリ使用量を監視してください。

SocketException：パイプの破損は、コードが接続の読み取りまたは書き込みを行っている間に、「もう一方の端」（クライアントまたはサーバー）が接続を閉じたことが原因で発生します。

これは、アプリケーション制御外のクライアントまたはサーバーからトラフィックを受信するクライアント/サーバーアプリケーションで非常に一般的な例外です。たとえば、クライアントはブラウザです。ブラウザーがAjax呼び出しを行うか、ユーザーがページまたはブラウザーを閉じるだけの場合、これによりすべての通信が予期せず効果的に終了する可能性があります。基本的には、もう一方の端がアプリケーションを終了するときにこのエラーが表示され、予期していませんでした。

アプリケーションでこの例外が発生した場合は、IO（入力/出力）が発生するコードを確認し、それをtry / catchブロックでラップして、このIOExceptionをキャッチする必要があります。その場合、この準有効な状況をどのように処理するかを決定するのはあなたです。

あなたの場合、あなたがまだ制御できる最も早い場所はHttpMethodDirector.executeWithRetry呼び出しです-したがって、呼び出しがtry / catchブロックでラップされていることを確認し、あなたが適切に見えるように処理してください。

デバッグ/トレースレベル以外では、SocketException-Broken Pipe固有のエラーをログに記録しないことを強くお勧めします。そうでない場合、これはログを埋めることにより、DOS（サービス拒否）攻撃の一形態として使用できます。この一般的なシナリオについて、アプリケーションを強化してネガティブテストを行ってください。

開いているすべてのストリームと接続を適切に閉じる必要があるため、次にurlConnectionオブジェクトを使用しようとしたときにエラーはスローされません。例として、次のコード変更によりエラーが修正されました。

前：

OutputStream out = new BufferedOutputStream(urlConnection.getOutputStream());
BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(out));
bw.write("Some text");
bw.close();
out.close();

後：

OutputStream os = urlConnection.getOutputStream();
OutputStream out = new BufferedOutputStream(os);
BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(out));
bw.write("Some text");
bw.close();
out.close();
os.close(); // This is a must.

FTPサーバーを介したデータダウンロード機能を実装しましたが、ダウンロードの再開中に同じ例外が見つかりました。この例外を解決するには、常に前のセッションから切断し、クライアントの新しいインスタンスとサーバーとの新しい接続を作成する必要があります。これと同じアプローチは、HTTPClientにも役立ちます。

特定のTCPをリッスンする単純なJavaアプリケーションを開発しているときにも、同じ問題が発生します。通常は問題ありませんでしたが、ストレステストを実行したところ、一部の接続でエラーが発生しました。socket write exception。

調査の後、私は自分の問題を解決する解決策を見つけました。私はこの質問がかなり古いことを知っていますが、私は私の解決策を共有することを好みます、誰かがそれを役に立つと感じることができます。

問題は、ServerSocketの作成でした。私はJavadocを読んでいますが、デフォルトの制限は50の保留ソケットです。別の接続を開こうとすると、これらは拒否されます。ソリューションは、サーバー側でこのデフォルト構成を変更するだけです。次のケースでは、TCPポートでリッスンし、保留中の10_000最大200ソケットを受け入れるソケットサーバーを作成します。

new Thread(() -> {
      try (ServerSocket serverSocket = new ServerSocket(10_000, 200)) {
        logger.info("Server starts listening on TCP port {}", port);

        while (true) {
          try {
            ClientHandler clientHandler = clientHandlerProvider.getObject(serverSocket.accept(), this);
            executor.execute(clientHandler::start);
          } catch (Exception e) {
            logger.error(e.getMessage());
          }
        }

      } catch (IOException | SecurityException | IllegalArgumentException e) {
        logger.error("Could not open server on TCP port {}. Reason: {}", port, e.getMessage());
      }
    }).start();

ServerSocketの Javadocから：

着信接続表示（接続要求）の最大キュー長は、バックログパラメータに設定されます。キューがいっぱいのときに接続指示が到着すると、接続は拒否されます。

問題は、デプロイされたファイルが正しいRMIメソッドで更新されていない可能性があります。RMIインターフェイスに更新されたパラメーター、またはクライアントにはない更新されたデータ構造があることを確認してください。または、RMIクライアントに、サーバーのバージョンとは異なるパラメーターがないこと。

これは単なる知識に基づく推測です。サーバーアプリケーションのクラスファイルを再デプロイして再テストした後、「壊れたパイプ」の問題はなくなりました。

上記の回答は、この理由を示してjava.net.SocketException: Broken pipeいます。もう一方の端が接続を閉じました。私がそれに遭遇したときに何が起こったかの経験を共有したいと思います：

1. クライアントのリクエストでは、 Content-Typeヘッダーがリクエスト本文よりも実際に大きく設定されている（実際には本文がまったくなかった）
2. Tomcatソケットの一番下のサービスはそのサイズのボディデータを待っていました（httpはTCP上にあり、カプセル化することで配信を保証します...）
3. 60秒が経過すると、tomcatはタイムアウト例外をスローします。 Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception java.net.SocketTimeoutException: null
4. タイムアウト例外のため、クライアントはステータスコード500の応答を受信します。
5. クライアントが接続を閉じる（応答を受信するため）。
6. java.net.SocketException: Broken pipeクライアントが閉じたため、tomcatがスローします。

ときどき、タイムアウト例外が接続を閉じるため、Tomcatが壊れたPIP例外をスローしないことがあります。そのような違いが私を混乱させる理由です。

JavaDoc：

着信接続指示（接続要求）の最大キュー長は50に設定されています。キューがいっぱいのときに接続指示が到着すると、接続は拒否されます。

たとえば、ServerSocketの「バックログ」パラメータを増やす必要があります。

int backlogSize = 50 ;
new ServerSocket(port, backlogSize);

原因は、リモートピアがソケットを閉じる（クラッシュなど）ためです。たとえば、リモートピアにデータを書き込もうとすると、これが発生します。それを解決するには、（catchを試行する）間のソケット操作の読み取り/書き込みを保護し、接続が失われた場合を管理してcatch（接続の更新、プログラムの停止など）に入れます。

 try {
      /* your code */
 } catch (SocketException e) {
      e.printStackTrace();
      /* insert your failure processings here */
 }