Haz todo lo posible por entender el código bien previamente a utilizarlo a tu proyecto si ttienes algo que aportar puedes comentarlo.
Solución:
Nos hemos encontrado con estos en un caso similar al tuyo. Por lo general, con mucha carga y no es fácil de reproducir en las pruebas. Todavía no lo he arreglado, pero estos son los pasos que seguimos.
Si se trata de un problema de firewall, obtendríamos una conexión rechazada o la excepción SocketTimeout.
1) ¿Puede rastrear estas solicitudes en el registro de acceso en el servidor? ¿Muestran un estado HTTP 200 o 404 o algo más? En nuestro caso, los registros del servidor (IIS en este caso) mostraron que el cliente cerró la conexión y no el servidor. Así que eso era un misterio.
Actualizar: Si el cliente siempre obtiene un 200, entonces el servidor en realidad envió alguna respuesta, pero sospecho que el tamaño de byte de la respuesta (si está registrado en los registros de acceso) mostrará un valor diferente al del tamaño de respuesta normal para esa solicitud.
Si muestra el mismo tamaño de respuesta, entonces tiene una condición (puede que no sea plausible) de que el servidor en realidad respondió correctamente pero el cliente no recibió la respuesta porque la conexión terminó en algún punto intermedio.
2) Los equipos de administración de la red observaron el tráfico TCP/IP para determinar qué extremo (o enrutador intermedio) está terminando la conversación HTTP/TCP-IP. Y una vez que entendemos qué extremo está terminando la conexión, debemos ver por qué. Alguien lo suficientemente informado podría ejecutar snoop
3) ¿Hay un número máximo de solicitudes configuradas/restringidas en el servidor, y eso está limitando sus conexiones?
4) ¿Existen balanceadores de carga intermedios en los que se puedan eliminar las solicitudes?
Actualizar: Una cosa más que queríamos, pero no completamos, es crear un static ruta entre el cliente y el servidor para reducir el número de saltos entre ellos y asegurar que no se caiga la conexión relacionada con la red. Ver http://en.wikipedia.org/wiki/Static_routing
5) Otra sugerencia es configurar ConnectTimeout también para ver si funcionan con un valor más alto.
Actualizar: Es posible que desee probar conn.getErrorStream()
Devuelve el flujo de error si la conexión falló pero, no obstante, el servidor envió datos útiles. Si la conexión no se conectó, o si el servidor no tuvo un error al conectarse o si el servidor tuvo un error pero no se enviaron datos de error, este método devolverá null.
6) También podría intentar tomar un conjunto de volcados de subprocesos en el servidor con 5 segundos de diferencia, para ver si algún subproceso muestra estas solicitudes entrantes en el servidor.
Actualizar: A partir de hoy, aprendimos a vivir con este problema, porque sumamos un índice de fallas de 200 a 300 de 400 000 solicitudes por día, que es 0.00075 %.
Sección de Reseñas y Valoraciones
Agradecemos que desees reafirmar nuestro análisis dejando un comentario y dejando una valoración te damos las gracias.