Что вызывает мою 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 мы имели, когда многие параллельные потоки вызывали веб-службу.
- перейдите в консоль администратора
- перейдите к "конфигурации"->"конфигурация сервера"->"пулы потоков"->"http-thread-pool".
- изменить настройку "максимальный размер пула потоков" с 5 до 32
- изменить настройку " Min Размер пула потоков" от 2 до 16
- Перезапустить 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 например.)