significa - ¿Qué está causando mi java.net.SocketException: restablecimiento de la conexión?

java socket exception error (12)

Estamos viendo frecuentes java.net.SocketException: Connection reset errores de java.net.SocketException: Connection reset en nuestros registros para un componente que llama a un servicio web de terceros que envía mensajes SMS.

Nuestra aplicación está escrita en Java y se ejecuta sobre Tomcat 5.5. Fue escrito por contratistas que ya no están con nosotros. El equipo actual no tiene experiencia real en Java, y no estamos seguros de dónde viene realmente el error de Connection reset la Connection reset , y cómo realizar la depuración.

El problema parece ser completamente intermitente y no relacionado con los mensajes que estamos tratando de enviar.

Cualquier sugerencia sobre cuáles podrían ser las causas típicas de esta excepción, y cómo podríamos proceder, son bienvenidas.

La pila de llamadas completa se incluye a continuación para completar.

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

Editar

La línea de nuestro código en el que se lanza la excepción 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 );

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 servidor al final de la conexión. Esto podría ser un problema con la solicitud que está enviando o un problema al final.

Para ayudar a la depuración, puede usar una herramienta como Wireshark para ver los paquetes de red reales. Además, ¿hay algún cliente alternativo a su código Java que pueda usar para probar el servicio web? Si esto fue exitoso, podría indicar un error en el código de Java.

Mientras usa Commons HTTP Client, eche un vistazo a la Guía común de registro de clientes HTTP . Esto le dirá cómo registrar la solicitud en el nivel HTTP.

En mi caso, esto fue porque mi Tomcat se configuró con un maxHttpHeaderSize insuficiente para una consulta SOLR particularmente complicada.

Espero que esto ayude a alguien por ahí!

Encontré este problema. Es causado por las sesiones bloqueadas en la base de datos relacionadas con las tablas que va a modificar a través del servicio web.

Encuentra las ID de sesión bloqueadas:

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

esto debería darle pistas sobre qué tabla está bloqueada, pero aún no completa la modificación.

Luego elimínelo en la v$session :

select * from v$session where sid = 99;

( 99 por ejemplo)

Este error ocurre de tu lado y NO del otro lado. Si el otro lado reinicia la conexión, el mensaje de excepción debería decir:

java.net.SocketException reset by peer

La causa es que la conexión dentro de HttpClient está obsoleta. Comprobar conexión obsoleta para SSL no soluciona este error. Solución: descargue su cliente y vuelva a crear.

Este error ocurre en el lado del servidor cuando el cliente cerró la conexión de socket antes de que la respuesta pudiera ser devuelta a través del socket. En una situación de aplicación web, no todos son peligrosos, ya que se pueden crear de forma manual. Por ejemplo, al salir del navegador antes de que se recuperara la respuesta.

La excepción significa que el socket se cerró inesperadamente desde el otro lado. Como está llamando a un servicio web, esto no debería suceder, lo más probable es que esté enviando una solicitud que desencadene un error en el servicio web.

Intente registrar la solicitud completa en esos casos, y vea si nota algo inusual. De lo contrario, póngase en contacto con el proveedor del servicio web y envíeles su solicitud problemática registrada.

Recibí este error cuando el archivo de texto que estaba tratando de leer contenía una cadena que coincidía con la firma de un antivirus en nuestro firewall.

Recibo este error todo el tiempo y lo considero normal.

Sucede cuando un lado intenta leer cuando el otro lado ya ha colgado. Por lo tanto, dependiendo del protocolo esto puede o no designar un problema . Si mi código de cliente indica específicamente al servidor que va a colgar, tanto el cliente como el servidor pueden colgar al mismo tiempo y este mensaje no ocurrirá.

La forma en que implemento mi código es que el cliente simplemente cuelgue sin despedirse. El servidor puede detectar el error e ignorarlo. En el contexto de HTTP, creo que un nivel del protocolo permite más de una solicitud por conexión mientras que el otro no.

Por lo tanto, puede ver cómo potencialmente un lado puede seguir colgando en el otro. Dudo que el error que está recibiendo sea de alguna preocupación pirata y simplemente podría atraparlo para evitar que llene sus archivos de registro.

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

La causa principal fue que nuestro servidor apache fue derribado para su implementación. Todo nuestro tráfico de terceros pasa a través de apache y recibimos un error de restablecimiento de la conexión debido a que está inactivo.

Si experimenta esto tratando de acceder a los servicios web implementados en un servidor Glassfish3, es posible que desee ajustar su configuración de grupo de subprocesos HTTP. Eso solucionaba SocketExceptions que teníamos cuando muchos hilos concurrentes llamaban al servicio web.

Ir a la consola de administración
Vaya a "Configuraciones" -> "Configuración del servidor" -> "Grupos de subprocesos" -> "http-thread-pool".
Cambie la configuración "Max Thread Pool Size" de 5 a 32
Cambie la configuración "Tamaño mínimo del grupo de subprocesos" de 2 a 16
Reinicie Glassfish.

También recibía exactamente ese error: Connection reset by peer . La excepción fue planteada por la plantilla REST de Spring al ejecutar el método postForObject() . Para mí, el problema fue una solicitud HTTP URL demasiado larga. Por lo tanto, primero compruebe si la URL producida es lo que debería ser y, si su servidor realmente debería poder manejar las solicitudes de esa longitud, simplemente vaya a la configuración del servidor y aumente la longitud permitida predeterminada de las solicitudes de URL.

Eso me solucionó el problema, pero tenga en cuenta que es posible que la aplicación no se ejecute en algunos buscadores de Internet, especialmente en los antiguos, ya que han corregido la longitud máxima de las solicitudes de URL.

Espero eso ayude...

También tropecé con este error. En mi caso, el problema era que estaba usando JRE6, con soporte para TLS1.0 . El servidor solo admite TLS1.2, por lo que se lanzó este error.