De hecho, actualmente estoy investigando conexiones de larga duración de una aplicación web basada en Java/Tomcat. Después de descartar cualquier motivo interno o basado en la aplicación, ahora estoy en la capa de red. La razón por la que estoy investigando este problema es que tenemos picos aparentemente aleatorios en nuestro monitoreo del tiempo de respuesta. Mientras investigaba, descubrí que este comportamiento no es tan aleatorio en absoluto, sino que se desencadena por ciertas solicitudes HTTP del cliente. Lo especial de esas conexiones es que todas se originan en la misma dirección IP y parecen usar un proxy Bluecoat, porque veo un encabezado HTTP x-bluecoat-via.
Como dije, la aplicación en sí funciona normalmente, solo el final de la conexión (desde el punto de vista de Tomcat) parece retrasarse de alguna manera. El servidor no habla directamente con el cliente, pero está detrás de un Loadbalancer F5 que en realidad debería almacenar en caché las respuestas (lo que podría no suceder debido a un encabezado de identidad de codificación de aceptación y a que la respuesta real es demasiado grande para el búfer).
Recibí un volcado de TCP, debido a un desafortunado error. Actualmente solo veo paquetes del LB al servidor de aplicaciones, no los paquetes reales enviados desde el servidor de aplicaciones.
El volcado contiene múltiples solicitudes en la misma conexión TCP/IP, lo que se debe a la agrupación de conexiones realizada por F5. La última solicitud HTTP en esta conexión es la conexión real que se marcó como de larga duración (925836,442 ms) en nuestro registro. Lo que veo son los paquetes de solicitud, una serie de ACK que me llevan a creer que el servidor de aplicaciones está escribiendo su respuesta y finalmente dos paquetes FIN, ACK seguidos de un RST, ACK que es el último paquete enviado por el F5.
Desde el punto de vista del tiempo, todo esto sucede en el transcurso de 250 ms, el último paquete se envía 15 minutos y 13 segundos antes de que vea el registro de respuesta en el servidor de aplicaciones, que se escribe después de que se cree que Tomcat finaliza la respuesta.
Estoy un poco sin ideas en este momento y tengo un par de preguntas abiertas:
¿Hay alguna razón por la que Linux mantenga abierta una conexión que haya recibido un RST y no se lo informe a la capa de aplicación?
¿Existe algún otro tiempo de espera que pueda provocar este comportamiento? Si este fuera el tiempo de espera de retransmisión de TCP, vería más RST del LB.
¿Alguna otra idea de por qué una conexión cerrada en el cable conduciría a una conexión aún abierta en la capa de aplicación?
¿Cómo puede algo que sucede en la capa de aplicación (solicitud HTTP especial) generar un comportamiento reproducible en la capa de transporte?
¿Quizás estoy completamente en el camino equivocado y este es un problema de mantenimiento de conexión dentro de Tomcat?
Respuesta1
Realmente no puedo ayudar en la capa de red, pero en Tomcat hay varios lugares donde puedes configurar eso.http://tomcat.apache.org/connectors-doc/reference/workers.html. Podrías intentar sobrescribir el tiempo de espera y configurarlo para cerrar la conexión después de un cierto período de tiempo.
En el enlace también tiene configuraciones del balanceador de carga que pueden ser útiles en su situación.