Como corrigir java.net.SocketException: Broken pipe?

Estou usando o cliente http apache commons para chamar url usando o método post para postar os parâmetros e está lançando o erro abaixo raramente.

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)

Alguém pode sugerir o que está causando essa exceção e como depurá-la?

Isso é causado por:

• geralmente, gravando em uma conexão quando a outra extremidade já a fechou;
• menos normalmente, o par fecha a conexão sem ler todos os dados que já estão pendentes no final.

Portanto, nos dois casos, você possui um protocolo de aplicativo mal definido ou implementado.

Há uma terceira razão que não documentarei aqui, mas que envolve o ponto de executar ações deliberadas para redefinir em vez de fechar adequadamente a conexão.

No nosso caso, experimentamos isso ao executar um teste de carga em nosso servidor de aplicativos. Ocorreu o problema de que precisamos adicionar memória adicional à nossa JVM porque ela estava acabando. Isso resolveu o problema.

Tente aumentar a memória disponível para a JVM e ou monitore o uso de memória quando receber esses erros.

SocketException: canal quebrado, é causado pelo 'outro lado' (o cliente ou o servidor) que fecha a conexão enquanto o seu código está lendo ou gravando na conexão.

Essa é uma exceção muito comum nos aplicativos cliente / servidor que recebem tráfego de clientes ou servidores fora do controle do aplicativo. Por exemplo, o cliente é um navegador. Se o navegador fizer uma chamada Ajax e / ou o usuário simplesmente fechar a página ou o navegador, isso poderá efetivamente eliminar toda a comunicação inesperadamente. Basicamente, você verá esse erro sempre que a outra extremidade finalizar o aplicativo e você não o esperava.

Se você tiver essa exceção no seu aplicativo, significa que deve verificar seu código onde a IO (entrada / saída) ocorre e envolvê-la com um bloco try / catch para capturar essa IOException. Cabe a você decidir como deseja lidar com essa situação semi-válida.

No seu caso, o primeiro local em que você ainda tem controle é a chamada para HttpMethodDirector.executeWithRetry- Portanto, assegure-se de que a chamada seja encerrada com o bloco try / catch e trate-a como achar melhor.

Eu recomendaria fortemente contra o registro de erros específicos de SocketException-Broken Pipe em algo diferente de níveis de depuração / rastreamento. Senão, isso pode ser usado como uma forma de ataque do DOS (Denial Of Service), preenchendo os logs. Tente fortalecer e testar negativamente seu aplicativo para esse cenário comum.

Todos os fluxos e conexões abertos precisam ser fechados corretamente, portanto, da próxima vez que tentarmos usar o objeto urlConnection, ele não emitirá um erro. Como exemplo, a seguinte alteração de código corrigiu o erro para mim.

Antes:

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

Depois de:

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.

Eu implementei a funcionalidade de download de dados através do servidor FTP e também encontrei a mesma exceção ao continuar o download. Para resolver essa exceção, você sempre precisará se desconectar da sessão anterior e criar uma nova instância do cliente e uma nova conexão com o servidor. Essa mesma abordagem também pode ser útil para o HTTPClient.

Eu tinha o mesmo problema enquanto desenvolvia um aplicativo Java simples que escuta um TCP específico. Normalmente, não tinha nenhum problema, mas quando executo algum teste de estresse, notei que alguma conexão quebrou com erro socket write exception.

Após a investigação, encontrei uma solução que resolve meu problema. Sei que essa pergunta é bastante antiga, mas prefiro compartilhar minha solução, alguém pode achar útil.

O problema estava na criação do ServerSocket. Eu li no Javadoc, há um limite padrão de 50 soquetes pendentes. Se você tentar abrir outra conexão, elas serão recusadas. A solução consiste simplesmente em alterar essa configuração padrão no lado do servidor. No caso a seguir, crio um servidor de soquete que escuta na porta TCP 10_000e aceita o máximo de 200soquetes pendentes.

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();

Do Javadoc do ServerSocket :

O comprimento máximo da fila para indicações de conexão de entrada (uma solicitação para conectar) é definido como o parâmetro backlog. Se uma indicação de conexão chegar quando a fila estiver cheia, a conexão será recusada.

O problema pode ser que seus arquivos implantados não são atualizados com os métodos RMI corretos. Verifique se sua interface RMI possui parâmetros atualizados ou estruturas de dados atualizadas que seu cliente não possui. Ou que seu cliente RMI não possui parâmetros diferentes da versão do servidor.

Este é apenas um palpite. Depois de reimplantar os arquivos de classe do meu aplicativo de servidor e testar novamente, o problema do "Tubo quebrado" desapareceu.

As respostas acima ilustram o motivo disso java.net.SocketException: Broken pipe: a outra extremidade fechou a conexão. Gostaria de compartilhar a experiência do que aconteceu quando o encontrei:

1. na solicitação de um cliente, o Content-Typecabeçalho é definido erroneamente como maior que o corpo da solicitação (na verdade, não havia nenhum corpo)
2. o serviço inferior no soquete do tomcat estava aguardando os dados do corpo dimensionado (http está no TCP, o que garante a entrega encapsulando e ...)
3. quando 60 segundos expiram, o tomcat lança a exceção de tempo limite: Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception java.net.SocketTimeoutException: null
4. o cliente recebe uma resposta com o código de status 500 devido à exceção de tempo limite.
5. conexão de fechamento do cliente (porque recebe resposta).
6. o tomcat lança java.net.SocketException: Broken pipeporque o cliente fechou.

Às vezes, o tomcat não lança uma exceção de pip quebrada, porque a exceção de tempo limite fecha a conexão, por que essa diferença está me confundindo também.

JavaDoc:

O comprimento máximo da fila para indicações de conexão de entrada (uma solicitação para conectar) é definido como 50. Se uma indicação de conexão chegar quando a fila estiver cheia, a conexão será recusada.

Você deve aumentar o parâmetro "backlog" do seu ServerSocket, por exemplo

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

A causa é que o ponto remoto fecha seu soquete (falha por exemplo); portanto, se você tentar gravar dados nele, por exemplo, você obterá isso. para resolver isso, proteja as operações de leitura / gravação no soquete entre (tente pegar) e gerencie o caso de perda de conexão no problema (renove a conexão, pare o programa, etc. etc):

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