Что вызывает мой java.net.SocketException: Connection reset?

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

Эта проблема не связана с сообщениями, которые мы пытаемся отправить.

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

Вот com.companyname.mtix.sms трассировка стека (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 );

Ответ 1

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

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

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

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

Как вы используете Commons HTTP Client, просмотрите Общее руководство по протоколу HTTP-клиентов. Это покажет вам, как регистрировать запрос на уровне HTTP.

Ответ 2

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

java.net.SocketException reset by peer

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

Найти заблокированные идентификаторы сеанса:

select * from v$lock l , all_objects a where l.TYPE ='TM' and l.id1 = a.OBJECT_ID;

это должно дать вам подсказки о том, какая таблица заблокирована, но еще не завершила модификацию.

Затем удалите его в v$session:

select * from v$session where sid = 99;

(99).