Что вызывает мое java.net.SocketException: сброс соединения?

Question

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

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

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

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

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

Answer 1

Javadoc для SocketException утверждает, что это

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

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

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

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

Answer 2

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

java.net.SocketException reset by peer

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

Answer 3

Если вы испытываете это при попытке получить доступ к веб-службам, развернутым на сервере Glassfish3, вы можете настроить параметры пула http-thread. Это исправило исключения SocketException, которые были у нас, когда многие параллельные потоки вызывали веб-сервис.

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

Answer 10

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

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