He visto esto más a menudo cuando un firewall corporativo en una estación de trabajo/computadora portátil se interpone en el camino, mata la conexión.

Eg. Tengo un proceso de servidor y un proceso de cliente en la misma máquina. El servidor está escuchando en todas las interfaces (0.0.0.0) y el cliente intenta una conexión a la interfaz pública/doméstica (no tenga en cuenta la interfaz de bucle invertido 127.0.0.1).

Si la máquina tiene su red desconectada (por ejemplo, wifi apagado), entonces se forma la conexión. Si la máquina es conectado a la red corporativa (directamente o vpn) entonces se forma la conexión.

Sin embargo, si la máquina está conectada a una wifi pública (o red doméstica), el firewall inicia y elimina la conexión. En esta situación, conectar el cliente a la interfaz loopback funciona bien, pero no a la interfaz home / public.

Espero que esto ayude.

Para probar qué componente falla, monitorizaría la comunicación TCP/IP usando wireshark y miraría quién está cerrando el puerto, también los tiempos de espera podrían ser relevantes.

El java.net.SocketException se lanza cuando hay un error creando o accediendo a un socket (como TCP). Esto generalmente puede ser causado cuando el servidor ha terminado la conexión (sin cerrarla correctamente), así que antes de obtener la respuesta completa. En la mayoría de los casos, esto puede ser causado por el problema de tiempo de espera (por ejemplo, la respuesta tarda demasiado tiempo o el servidor está sobrecargado con las solicitudes), o el cliente envió el SYN, pero no recibió ACK (reconocimiento de la conexión rescisión). Para problemas de tiempo de espera, puede considerar aumentar el valor de tiempo de espera.

La Excepción de socket generalmente viene con el mensaje de detalle especificado sobre el problema.

Ejemplo de mensajes detallados:

• El software provocó el aborto de la conexión: recv falló.

  El error indica un intento de enviar el mensaje y la conexión ha sido abortada por su servidor. Si esto sucedió mientras se conectaba a la base de datos, esto puede estar relacionado con usando no es compatible Connector/J controlador JDBC.

  Posible solución: Asegúrese de tener bibliotecas/controladores adecuados en su CLASSPATH.

• El software provocó el aborto de la conexión: connect.

  Esto puede suceder cuando hay un problema para conectarse al control remoto. Por ejemplo debido a que el comprobador de virus rechaza las solicitudes de correo remoto.

  Posible solución: Compruebe el servicio de análisis de virus si está bloqueando el puerto para la salida solicitudes de conexiones.

• El software causó el aborto de conexión: error de escritura de socket.

  Posible solución: Asegúrese de que está escribiendo la longitud correcta de bytes en la secuencia. Así que vuelve a comprobar lo que estás enviando. Ver este hilo .

• Conexión restablecida por el par: error de escritura del socket / Conexión abortada por el par: error de escritura del socket

  La aplicación no comprobó si la conexión keep-alive había sido tiempo fuera en el lado del servidor.

  Posible solución: Asegúrese de que el HttpClient no sea nulo antes de leer desde la conexión.^E13222_01

• Conexión restablecida por el par.

  La conexión ha sido terminada por el par (servidor).

• Restablecimiento de la conexión.

  La conexión ha sido terminada por el cliente o cerrada por el extremo servidor de la conexión debido a la solicitud con el solicitud.

  Ver: ¿Qué está causando mi java.net.SocketException: Restablecimiento de conexión?

¿Ha comprobado el código fuente de Tomcat y el código fuente de JVM ? Eso puede darte más ayuda.

Creo que su pensamiento general es bueno. Yo esperaría un ConnectException en el escenario que no se podía conectar. Lo anterior parece muy orientado al cliente.

Para cualquiera que use programas simples de Cliente Servidor y obtenga este error, es un problema de flujos de entrada o Salida no cerrados (o cerrados a principios).

Me enfrentaba al mismo problema.
Comúnmente Este tipo de error ocurre debido a que el cliente ha cerrado su conexión y el servidor aún intenta escribir en ese cliente.
Por lo tanto, asegúrese de que su cliente tenga su conexión abierta hasta que el servidor termine con su outputstream.
Y una cosa más, No se olvide de cerrar flujo de entrada y salida.

Espero que esto ayude.
Y si todavía se enfrenta a la cuestión de informar a su problema aquí en detalles.

Este error me sucedió mientras probaba mi servicio soap con el cliente SoapUI, básicamente estaba tratando de obtener un mensaje muy grande (>500kb) y SoapUI cerró la conexión por tiempo de espera.

En SoapUI ir a:

Archivo Preferences > Preferencias Tim Tiempo de espera del socket (ms)

...y poner un valor grande, como 180000 (3 minutos), esto no será la solución perfecta para su problema porque el archivo es de hecho a grande, pero al menos tendrá una respuesta.

Conexión Cerrada en otro cliente

En mi caso, el error fue:

java.net.SocketException: Software caused connection abort: recv failed

Se recibió en eclipse mientras depuraba una aplicación java accediendo a una base de datos H2. La fuente del error fue que inicialmente había abierto la base de datos con SQuirreL para verificar manualmente la integridad. Usé la bandera para habilitar múltiples conexiones a la misma base de datos (es decir, AUTO_SERVER=TRUE), por lo que no hubo ningún problema para conectarse a la base de datos desde java.

El error apareció cuando, después de un tiempo is largo proceso de Java decided Decidí cerrar Ardilla a los recursos libres. Parece como si SQuirreL fuera el que "posee" la instancia del servidor DB y que se apagó con la conexión de SQuirreL.

Reiniciar la aplicación Java no produjo el error de nuevo.

config

• Windows 7
• Eclipse Kepler
• Ardilla 3.6
• org.h2.Driver ver 1.4.192

Mi servidor estaba lanzando esta excepción en el paso 2 días y lo resolví moviendo la función de desconexión con:

outputStream.close();
inputStream.close();
Client.close();

Al final del hilo de la lista. si va a ayudar a alguien.

En la situación explicada a continuación, el lado del cliente lanzará tal excepción:

Se le pide al servidor que autentique el certificado del cliente, pero el cliente proporciona un certificado que el Uso extendido de la clave no admite la autenticación del cliente, por lo que el servidor no acepta el certificado del cliente y luego cierra la conexión.

Me enfrentaba al mismo problema con wireMock mientras se burlaba de las llamadas a la API rest. Antes estaba definiendo el servidor de esta manera:

WireMockServer wireMockServer = null;

Pero debe definirse como se muestra a continuación:

@Rule 
public WireMockRule wireMockRule = new WireMockRule(8089);