Pregunta

    

Esta pregunta ya tiene una respuesta aquí:

         

Estamos viendo errores java.net.SocketException: Connection reset frecuentes, pero los intermitentes en nuestros registros. No estamos seguros en cuanto a donde el error Connection reset en realidad proviene de, y cómo ir sobre la depuración.

El problema parece estar relacionado con los mensajes que estamos tratando de enviar. Tenga en cuenta que el mensaje es no connection reset by peer.

¿Alguna sugerencia sobre cuáles podrían ser las causas típicas de esta excepción, y cómo podríamos proceder?

Aquí es un seguimiento de pila representante (com.companyname.mtix.sms es nuestro 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)
    

Nuestro componente es una aplicación web, se ejecuta en Tomcat, que llama a un tercer servicio Web partido que envía mensajes SMS, se da la circunstancia. La línea de nuestro código en los que la excepción se tira de es la última línea en el fragmento de código a continuación.

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 );
¿Fue útil?

Solución

El Javadoc para SocketException afirma que es

  

Lanzado para indicar que hay un error en el protocolo subyacente, como un error de TCP

En su caso, parece que la conexión ha sido cerrada por el lado del servidor de la conexión. Esto podría ser un problema con la solicitud que está enviando o un problema en su extremo.

Para facilitar la depuración se podría contemplar la utilización de una herramienta como Wireshark para ver los paquetes de red reales. Además, ¿hay un cliente alternativa a su código Java que se puede utilizar para probar el servicio web? Si esto fue un éxito que podría indicar un error en el código Java.

Como se está utilizando cliente HTTP Commons echar un vistazo a la Registro de cliente HTTP Común Guía . Esto le dirá cómo registrar la solicitud en el nivel HTTP.

Otros consejos

Este error pasa a su lado y no el otro lado. Si el otro lado restablece la conexión, entonces el mensaje de excepción debe decir:

java.net.SocketException reset by peer

La causa es la conexión en el interior HttpClient es rancio. Comprobar la conexión rancio para SSL no corrige este error. Solución:. Volcar su cliente y recrear

Si experimenta este tratando de acceder a los servicios web implementados en el servidor Glassfish3, es posible que desee ajustar la configuración http hilos de la piscina. Que SocketExceptions fijos que tenían cuando tantos procesos simultáneos estaba llamando al servicio web.

  1. Ir a la consola de administración
  2. Vaya a "Configuraciones" -> "configuración del servidor" -> "grupos de subprocesos" -> "http-thread-pool"
  3. .
  4. Cambiar configuración "Max Tamaño de rosca Pool" de 5 a 32
  5. Cambiar configuración de "Tamaño mínimo del hilo Pool" de 2 a 16
  6. Reiniciar Glassfish.

También me tropiezo con este error. En mi caso, el problema era que estaba usando jre6, con soporte para TLS1.0 . El servidor sólo se admite TLS1.2, por lo que fue lanzada este error.

En mi caso, esto se debió a mi Tomcat se estableció con un maxHttpHeaderSize insuficiente para una consulta SOLR particularmente complicado.

Espero que esto ayude a alguien por allí!

Me sale este error todo el tiempo y considero que es normal.

Esto ocurre cuando una parte trata de leer cuando la otra parte ya se ha colgado. Por lo tanto dependiendo del protocolo de esto puede o no designar un problema . Si mi código de cliente indica específicamente al servidor que se va a colgar, a continuación, el cliente y el servidor pueden colgar al mismo tiempo y este mensaje no sucederían.

A mi modo de implementar mi código es para que el cliente acaba de colgar sin decir adiós. El servidor puede detectar el error e ignorarlo. En el contexto de HTTP, creo un nivel del protocolo permite que más de una petición por conexión mientras que el otro no.

Así se puede ver cómo potencialmente un lado podía mantener colgar en el otro. Dudo que el error que está recibiendo es de ninguna preocupación de piratería y simplemente podía cogerlo para evitar que se llene los archivos de registro.

Este error se produce en el lado de servidor cuando el cliente cierra la conexión de socket antes de la respuesta podría ser devuelto sobre el zócalo. En un escenario de aplicación web no todos ellos son peligrosos, ya que pueden crearse manualmente. Por ejemplo, al dejar de fumar el navegador antes de que se recuperó el reponse.

La excepción significa que la toma de corriente se cerró de forma inesperada desde el otro lado. Puesto que usted está llamando a un servicio web, esto no debería ocurrir - más probable es que va a enviar una solicitud que desencadena un error en el servicio web.

Trate de registrar toda la solicitud en esos casos, y ver si nota algo inusual. De lo contrario, póngase en contacto con el proveedor de servicios web y enviarles su solicitud problemática iniciado sesión.

Sé que este hilo es poco viejo, pero me gustaría añadir mis 2 centavos. Tuvimos el mismo error "restablecimiento de conexión" justo después de nuestra uno de los lanzamientos.

La causa principal fue, nuestro servidor apache fue derribado para su despliegue. Todo nuestro tráfico tercero pasa a través de apache y nos iban a dar restablecimiento de la conexión de error debido a que es hacia abajo.

Este es un hilo viejo, pero me encontré con java.net.SocketException: Connection reset ayer.

La aplicación del lado del servidor tenía su configuración de límite cambiados para permitir sólo el 1 conexión a la vez! Por lo tanto, a veces llamadas fue a través y en otras no. He resuelto el problema cambiando las configuraciones de límite.

Me estaba exactamente ese error también: Connection reset by peer. La excepción se había planteado por la plantilla de descanso de primavera después de ejecutar el método postForObject(). Para mí el problema fue la petición HTTP URL demasiado tiempo. Así que primero comprobar si la URL producido es lo que debería ser y, si el servidor debería ser capaz de manejar las peticiones de esa longitud, sólo tiene que ir a la configuración del servidor y aumentar la longitud permitida por defecto de las peticiones de URL.

Esto resuelve el problema para mí, pero tenga en cuenta:. La aplicación podría no funcionar en algunos navegadores de Internet, especialmente los antiguos, ya que tienen una longitud fija máxima de peticiones de URL

Espero que ayuda ...

Tengo este error cuando el archivo de texto que estaba tratando de leer contenía una cadena que coincide con una firma de antivirus en nuestro servidor de seguridad.

Fwiw, que estaba recibiendo este error cuando estaba haciendo accidentalmente una solicitud GET a un punto final que se espera una solicitud POST. Es de suponer que era sólo que determinados servidores manera de manejar el problema.

Me estaba este error porque el puerto intenté conectar a estaba cerrado.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top