Как исправить java.net.SocketException: сломанная труба?

Я использую Apache http клиента клиента для вызова URL, используя метод post для публикации параметров, и редко выдает ошибку ниже.

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)

Может кто-нибудь подсказать, что вызывает это исключение и как его отладить?

Это вызвано:

• чаще всего, запись в соединение, когда другой конец уже закрыл его;
• реже, одноранговый узел закрывает соединение, не считывая все данные, которые уже ожидают в его конце.

Таким образом, в обоих случаях у вас есть плохо определенный или реализованный протокол приложения.

Есть третья причина, которую я не буду здесь документировать, но которая заключается в том, что одноранговый узел предпринимает преднамеренные действия для сброса, а не для правильного закрытия соединения.

В нашем случае мы столкнулись с этим при выполнении нагрузочного теста на нашем сервере приложений. Выяснилось, что нам нужно добавить дополнительную память в нашу 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.

У меня была такая же проблема, когда я разрабатывал простое Java-приложение, которое прослушивает определенный TCP. Обычно у меня не возникало проблем, но при запуске стресс-теста я заметил, что какое-то соединение оборвалось с ошибкойsocket write exception .

После расследования я нашел решение, которое решает мою проблему. Я знаю, что этот вопрос довольно старый, но я предпочитаю поделиться своим решением, кто-то может найти его полезным.

Проблема была в создании ServerSocket. Я читал из Javadoc, есть ограничение по умолчанию в 50 ожидающих сокетов. Если вы попытаетесь открыть другое соединение, вам будет отказано. Решение состоит просто в изменении конфигурации по умолчанию на стороне сервера. В следующем случае я создаю сервер Socket, который прослушивает порт 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();

Из Javadoc ServerSocket :

Максимальная длина очереди для индикации входящих соединений (запрос на соединение) задается параметром backlog. Если индикация соединения появляется, когда очередь заполнена, соединение отклоняется.

Проблема может заключаться в том, что ваши развернутые файлы не обновляются с правильными методами 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 не генерирует исключение нарушенного пункта, потому что исключение тайм-аута закрывает соединение, поэтому такая разница меня смущает.

JavaDoc:

Максимальная длина очереди для индикаций входящего соединения (запроса на соединение) установлена ​​равной 50. Если индикация соединения приходит, когда очередь заполнена, соединение отклоняется.

Вы должны увеличить параметр "backlog" вашего ServerSocket, например

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

Причина в том, что удаленный узел закрывает свой сокет (например, сбой), поэтому, если вы попытаетесь записать данные для него, например, вы получите это. чтобы решить эту проблему, защитите операции чтения / записи в сокет между (попытайтесь перехватить), затем перенесите случай потери соединения в перехват (обновить соединение, остановить программу и т. д.):

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