Что вызывает мой java.net.SocketException: сброс подключения?

Мы видим частые, но периодические java.net.SocketException: Connection reset ошибки в наших журналах. Мы не уверены, откуда на Connection reset самом деле возникает ошибка и как проводить отладку.

Проблема, похоже, не связана с сообщениями, которые мы пытаемся отправить. Обратите внимание, что сообщения нет connection reset by peer .

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

Вот типичная трассировка стека ( com.companyname.mtix.sms это наш компонент):

    java.net.SocketException: сброс подключения
        в java.net.SocketInputStream.read (SocketInputStream.java:168)
        в java.io.BufferedInputStream.fill (BufferedInputStream.java:218)
        в java.io.BufferedInputStream.read (BufferedInputStream.java:235)
        на org.apache.commons.httpclient.HttpParser.readRawLine (HttpParser.java:77)
        на org.apache.commons.httpclient.HttpParser.readLine (HttpParser.java:105)
        в org.apache.commons.httpclient.HttpConnection.readLine (HttpConnection.java:1115)
        в org.apache.commons.httpclient.HttpMethodBase.readStatusLine (HttpMethodBase.java:1832)
        в org.apache.commons.httpclient.HttpMethodBase.readResponse (HttpMethodBase.java:1590)
        в org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:995)
        в org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry (HttpMethodDirector.java:397)
        в org.apache.commons.httpclient.HttpMethodDirector.executeMethod (HttpMethodDirector.java:170)
        в org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:396)
        в org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:324)
        в com.companyname.mtix.sms.services.impl.message.SendTextMessage.sendTextMessage (SendTextMessage.java:127)
        в com.companyname.mtix.sms.services.MessageServiceImpl.sendTextMessage (MessageServiceImpl.java:125)
        в com.companyname.mtix.sms.services.remote.MessageServiceRemoteImpl.sendTextMessage (MessageServiceRemoteImpl.java:43)
        at sun.reflect.GeneratedMethodAccessor203.invoke (Неизвестный источник)
        в sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25)
        в java.lang.reflect.Method.invoke (Method.java:585)
        в org.apache.axis.providers.java.RPCProvider.invokeMethod (RPCProvider.java:397)
        в org.apache.axis.providers.java.RPCProvider.processMessage (RPCProvider.java:186)
        в org.apache.axis.providers.java.JavaProvider.invoke (JavaProvider.java:323)
        в org.apache.axis.strategies.InvocationStrategy.visit (InvocationStrategy.java:32)
        в org.apache.axis.SimpleChain.doVisiting (SimpleChain.java:118)
        в org.apache.axis.SimpleChain.invoke (SimpleChain.java:83)
        в org.apache.axis.handlers.soap.SOAPService.invoke (SOAPService.java:453)
        на org.apache.axis.server.AxisServer.invoke (AxisServer.java:281)
        в org.apache.axis.transport.http.AxisServlet.doPost (AxisServlet.java:699)
        в javax.servlet.http.HttpServlet.service (HttpServlet.java:709)
        в org.apache.axis.transport.http.AxisServletBase.service (AxisServletBase.java:327)
        в javax.servlet.http.HttpServlet.service (HttpServlet.java:802)
        в org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:252)
        в org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:173)
        в com.companyname.mtix.sms.http.filters.NoCacheFilter.doFilter (NoCacheFilter.java:63)
        в org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:202)
        в org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:173)
        на com.companyname.mtix.sms.http.filters.MessageFilter.doFilter (MessageFilter.java:53)
        в org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:202)
        в org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:173)
        в org.springframework.web.filter.RequestContextFilter.doFilterInternal (RequestContextFilter.java:61)
        в org.springframework.web.filter.OncePerRequestFilter.doFilter (OncePerRequestFilter.java:77)
        в org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:202)
        в org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:173)
        в org.ajaxanywhere.AAFilter.doFilter (AAFilter.java:46)
        в org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:202)
        в org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:173)
        в org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:213)
        в org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:178)
        в org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:126)
        в org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105)
        в org.apache.catalina.valves.AccessLogValve.invoke (AccessLogValve.java:541)
        в org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:107)
        в org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:148)
        в org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:869)
        в org.apache.coyote.http11.Http11BaseProtocol $ Http11ConnectionHandler.processConnection (Http11BaseProtocol.java:664)
        в org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket (PoolTcpEndpoint.java:527)
        в org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt (LeaderFollowerWorkerThread.java:80)
        в org.apache.tomcat.util.threads.ThreadPool $ ControlRunnable.run (ThreadPool.java:684)
        в java.lang.Thread.run (Thread.java:595)
    

Наш компонент - это веб-приложение, работающее под управлением Tomcat, которое вызывает стороннюю веб-службу, которая отправляет SMS-сообщения, так бывает. Строка нашего кода, из которой возникает исключение, является последней строкой в ​​фрагменте кода ниже.

String aggregatorResponse = null;
HttpClient httpClient = prepareHttpClient( username, password );
PostMethod postMethod = preparePostMethod( textUrl );

try {
  SybaseTextMessageBuilder builder = new SybaseTextMessageBuilder();
  URL notifyUrl = buildNotificationUrl( textMessage, codeSetManager );
  String smsRequestDocument = builder.buildTextMessage( textMessage, notifyUrl );
  LOG.debug( "Sybase MT document created as: \n" + smsRequestDocument );

  postMethod.setRequestEntity( new StringRequestEntity( smsRequestDocument ) );
  LOG.debug( "commiting SMS to aggregator: " + textMessage.toString() );
  int httpStatus = httpClient.executeMethod( postMethod );

Ответов (14)

Решение

В javadoc для SocketException указано, что это

Брошено, чтобы указать, что в базовом протоколе есть ошибка, например ошибка TCP.

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

Чтобы облегчить отладку, вы можете использовать такой инструмент, как Wireshark, для просмотра реальных сетевых пакетов. Кроме того, есть ли альтернативный клиент к вашему Java-коду, который вы могли бы использовать для тестирования веб-службы? Если это было успешно, это могло указывать на ошибку в коде Java.

Поскольку вы используете Commons HTTP Client, ознакомьтесь с Руководством по ведению журнала Common HTTP Client . Это расскажет вам, как регистрировать запрос на уровне HTTP.

Если вы столкнулись с этим при попытке получить доступ к веб-службам, развернутым на сервере Glassfish3, вы можете настроить параметры пула HTTP-потоков. Эти фиксированные SocketExceptions были, когда множество параллельных потоков вызывали веб-службу.

  1. Перейти в консоль администратора
  2. Перейдите в «Конфигурации» -> «Конфигурация сервера» -> «Пулы потоков» -> «http-thread-pool».
  3. Измените настройку «Максимальный размер пула потоков» с 5 на 32.
  4. Измените настройку «Мин. Размер пула потоков» с 2 на 16.
  5. Перезапустите Glassfish.

В моем случае это произошло из-за того, что в моем Tomcat было установлено значение, недостаточное maxHttpHeaderSize для особо сложного запроса SOLR.

Надеюсь, это кому-то поможет!

Я тоже наткнулся на эту ошибку. В моем случае проблема заключалась в том, что я использовал JRE6 с поддержкой TLS1.0 . Сервер поддерживал только TLS1.2, поэтому возникла эта ошибка.

Я знаю, что эта ветка немного устарела, но хотел бы добавить свои 2 цента. У нас была такая же ошибка «сброса соединения» сразу после одного из наших релизов.

Основная причина заключалась в том, что наш apache сервер был отключен для развертывания. Весь наш сторонний трафик проходит, apache и мы получали ошибку сброса соединения из-за того, что он не работал.

Это старая ветка, но я java.net.SocketException: Connection reset вчера наткнулся на нее.

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

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

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

Я получал эту ошибку, потому что порт, к которому я пытался подключиться, был закрыт.

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

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

Эта ошибка возникает на стороне сервера, когда клиент закрыл соединение сокета до того, как ответ мог быть возвращен через сокет. В сценарии веб-приложения не все из них опасны, поскольку их можно создать вручную. Например, закрыв браузер до получения ответа.

Эта ошибка возникает на вашей стороне, а НЕ на другой стороне. Если другая сторона сбрасывает соединение, в сообщении об исключении должно быть указано:

java.net.SocketException reset by peer

Причина в том, что соединение внутри HttpClient устарело. Проверка устаревшего соединения для SSL не устраняет эту ошибку. Решение: сбросьте своего клиента и воссоздайте.

Я получаю эту ошибку постоянно и считаю ее нормальным явлением.

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

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

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

Я получаю именно эту ошибку тоже: Connection reset by peer . Исключение было вызвано шаблоном REST Spring при запуске postForObject() метода. Для меня проблема заключалась в слишком длинном запросе URL-адреса HTTP. Поэтому сначала проверьте, соответствует ли созданный URL-адрес тому, каким он должен быть, и, если ваш сервер действительно должен иметь возможность обрабатывать запросы такой длины, просто перейдите в конфигурацию сервера и увеличьте разрешенную по умолчанию длину запросов URL-адресов.

Это решило проблему для меня, но имейте в виду: приложение может не работать в некоторых интернет-браузерах, особенно в старых, поскольку они имеют фиксированную максимальную длину URL-запросов.

Надеюсь, это поможет...