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

мы видим часто java.net.SocketException: Connection reset ошибки в наших журналах для компонента, который вызывает стороннюю веб-службу, которая отправляет SMS-сообщения.

наше приложение написано на Java и работает на базе Tomcat 5.5. Его написали подрядчики, которых больше нет с нами. Текущая команда не имеет реального опыта Java, и мы не уверены, где Connection reset ошибка на самом деле и откуда, и как идти об отладке.

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

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

весь стек вызовов включен ниже для полноты.

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

редактировать

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

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

13 ответов


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

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

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

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

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


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

java.net.SocketException reset by peer

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


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

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

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

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


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


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

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

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

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


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

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


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


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

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


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

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


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

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

надеюсь, что это помогает...


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


я столкнулся с этой проблемой. Это вызвано заблокированными сеансами в базе данных, которые связаны с таблицами, которые вы собираетесь изменить через 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 например.)