O que está causando meu java.net.SocketException: Conexão redefinida?



nested exception is: java.net.socketexception: connection reset tradução (12)

Estamos vendo java.net.SocketException: Connection reset freqüente, mas intermitente java.net.SocketException: Connection reset erros de java.net.SocketException: Connection reset em nossos registros. Não temos certeza de onde o erro de Connection reset da Connection reset está realmente vindo e como proceder para a depuração.

O problema parece não estar relacionado às mensagens que estamos tentando enviar. Note que a mensagem não é connection reset by peer .

Alguma sugestão sobre quais podem ser as causas típicas dessa exceção e como podemos proceder?

Aqui está um rastreamento de pilha representativo ( com.companyname.mtix.sms é nosso componente):

    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)
    

Nosso componente é um aplicativo da web, executado sob o Tomcat, que chama um serviço da Web de terceiros que envia mensagens SMS, por acaso. A linha do nosso código em que a exceção é lançada é a última linha no trecho de código abaixo.

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

Eu recebo esse erro o tempo todo e considero normal.

Acontece quando um lado tenta ler quando o outro lado já desligou. Assim, dependendo do protocolo, isso pode ou não designar um problema . Se o código do meu cliente indicar especificamente para o servidor que ele irá desligar, tanto o cliente quanto o servidor poderão desligar ao mesmo tempo e essa mensagem não acontecerá.

A maneira como eu implemento o meu código é para o cliente simplesmente desligar sem dizer adeus. O servidor pode, então, pegar o erro e ignorá-lo. No contexto do HTTP, acredito que um nível do protocolo permite mais de um pedido por conexão enquanto o outro não.

Assim, você pode ver como potencialmente um lado poderia ficar pendurado no outro. Eu duvido que o erro que você está recebendo seja de qualquer preocupação pirata e você poderia simplesmente pegá-lo para evitar que ele enchesse seus arquivos de log.


A exceção significa que o soquete foi fechado inesperadamente do outro lado. Como você está chamando um serviço da web, isso não deve acontecer - provavelmente você está enviando uma solicitação que aciona um bug no serviço da web.

Tente registrar a solicitação inteira nesses casos e veja se você percebe algo incomum. Caso contrário, entre em contato com o provedor de serviços da Web e envie-lhes sua solicitação problemática registrada.


No meu caso, isso ocorreu porque meu Tomcat foi configurado com um maxHttpHeaderSize insuficiente para uma consulta SOLR particularmente complicada.

Espero que isto seja útil a alguém!


Se você experimentar essa tentativa de acessar os serviços da Web implantados em um servidor Glassfish3, talvez queira ajustar suas configurações de pool de http-thread. Isso corrigiu SocketExceptions que tivemos quando muitos threads simultâneos estavam chamando o serviço da web.

  1. Ir para o Admin Console
  2. Navegue até "Configurações" -> "Configuração do servidor" -> "Conjuntos de segmentos" -> "http-thread-pool".
  3. Alterar a configuração "Tamanho máximo do pool de threads" de 5 a 32
  4. Alterar a configuração "Min Thread Pool Size" de 2 a 16
  5. Reinicie o Glassfish.

Eu sei que esta discussão é pouco antiga, mas gostaria de adicionar meus 2 centavos. Tivemos o mesmo erro de "reset de conexão" logo após nosso lançamento.

A causa principal foi que nosso servidor apache foi desativado para implementação. Todo o tráfego de terceiros passa pelo apache e estamos recebendo o erro de redefinição de conexão devido a ele estar inativo.


Eu estava recebendo esse erro porque a porta que eu tentei conectar foi fechada.


Eu também tropecei nesse erro. No meu caso, o problema era que eu estava usando o JRE6, com suporte para TLS1.0 . O servidor suportava apenas o TLS1.2, portanto, esse erro foi lançado.


Este erro ocorre no lado do servidor quando o cliente fechou a conexão do soquete antes que a resposta pudesse ser retornada sobre o soquete. Em um cenário de aplicativo da Web, nem todos são perigosos, pois podem ser criados manualmente. Por exemplo, encerrando o navegador antes que a resposta seja recuperada.


O javadoc para SocketException declara que é

Lançada para indicar que há um erro no protocolo subjacente, como um erro do TCP

No seu caso, parece que a conexão foi fechada pelo servidor final da conexão. Isso pode ser um problema com a solicitação que você está enviando ou com um problema no final.

Para ajudar na depuração, você pode usar uma ferramenta como o Wireshark para visualizar os pacotes de rede reais. Além disso, existe um cliente alternativo para o seu código Java que você poderia usar para testar o serviço da web? Se isso foi bem sucedido, isso pode indicar um erro no código Java.

Como você está usando o Commons HTTP Client, dê uma olhada no Common Log Client do Windows . Isto irá dizer-lhe como registrar a solicitação no nível HTTP.


Este erro acontece do seu lado e NÃO do outro lado. Se o outro lado redefinir a conexão, a mensagem de exceção deve dizer:

java.net.SocketException reset by peer

A causa é que a conexão dentro do HttpClient é obsoleta. Verifique se a conexão obsoleta para SSL não corrige esse erro. Solução: despeje seu cliente e recrie.


Eu estava recebendo exatamente esse erro também: Connection reset by peer . A exceção estava sendo levantada pelo modelo REST do Spring ao executar o método postForObject() . Para mim, o problema foi muito longo solicitação HTTP URL. Então, primeiro verifique se a URL produzida é o que deveria ser e, se o seu servidor realmente deve ser capaz de lidar com solicitações desse tamanho, simplesmente vá para a configuração do servidor e aumente o tamanho permitido padrão de solicitações de URL.

Isso resolveu o problema para mim, mas esteja ciente: o aplicativo pode não ser executado em alguns navegadores da Internet, especialmente os antigos, pois eles corrigiram o tamanho máximo das solicitações de URL.

Espero que ajude...


Eu encontrei esse problema. É causado pelas sessões bloqueadas no banco de dados relacionadas às tabelas que você irá modificar através do Webservice.

Encontre os IDs de sessão bloqueados:

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

isso deve fornecer pistas sobre qual tabela está bloqueada, mas ainda não concluiu a modificação.

Em seguida, exclua-o na v$session :

select * from v$session where sid = 99;

( 99 por exemplo)





connection-reset