(Conexiones de red) bytes atrapado en cola de envío durante 15 minutos; ¿por qué?

Question

Tengo un programa Java que se ejecuta en Windows (una máquina de Citrix), que envía una petición a los servidores de aplicaciones Java en Linux; este mecanismo de reenvío es todo personalizado.

El programa de Windows de Java (vamos a llamarlo W) abre un socket de escucha a un puerto determinado por el sistema operativo, por ejemplo 1234 para recibir los resultados. A continuación, se invoca un servicio de "expedición" en el servidor con una "solicitud de negocio". Este servicio se divide la solicitud y la envía a otros servidores (llamémosles S1 ... Sn), y devuelve el número de puestos de trabajo para el cliente de forma sincrónica.

En mis pruebas, hay 13 puestos de trabajo, enviados a un número de servidores y dentro de 2 segundos, todos los servidores han terminado de procesar su trabajo y tratan de enviar los resultados de vuelta a la toma del W.

I puede ver en los registros que 9 empleos son recibidos por W (este número varía de una prueba a). Por lo tanto, trato de buscar a los 4 restantes puestos de trabajo. Si hago un netstat en esta caja de Windows, veo que 4 zócalos están abiertas:

TCP    W:4373       S5:48197  ESTABLISHED
TCP    W:4373       S5:48198  ESTABLISHED
TCP    W:4373       S6:57642  ESTABLISHED
TCP    W:4373       S7:48295  ESTABLISHED

Si hago un vertedero de hilo de W, veo 4 hilos que tratan de leer de estas tomas, y aparentemente atrapado en java.net.SocketInputStream.socketRead0(Native Method).

Si voy en cada una de las cajas S y hacer un netstat, veo que algunos bytes se encuentran todavía en la cola de envío. Este número de bytes no se mueve durante 15 minutos. (La siguiente es la agregación de netstats en las diferentes máquinas):

Proto Recv-Q Send-Q Local Address               Foreign Addr   State
tcp        0   6385 S1:48197                          W:4373   ESTABLISHED
tcp        0   6005 S1:48198                          W:4373   ESTABLISHED
tcp        0   6868 S6:57642                          W:4373   ESTABLISHED
tcp        0   6787 S7:48295                          W:4373   ESTABLISHED

Si hago un vertedero de hilo de los servidores, veo los hilos también están atrapados en java.net.SocketInputStream.socketRead0(Native Method). Yo esperaría que una escritura, pero tal vez están a la espera de un ACK? (No estoy seguro de que aquí;?? Tendría que mostrar en Java ¿No debería ser manejado por el protocolo TCP directamente)

Ahora, la cosa es muy extraño: después de 15 minutos (y siempre es 15 minutos), los resultados se reciben, los zócalos están cerradas, y todo continúa de forma normal.

Esto solía trabajar siempre antes. Los servidores S trasladaron a un centro de datos diferente, por lo W y S ya no está en el mismo centro de datos son. Además, S está detrás de un cortafuegos. Todos los puertos deben ser autorizadas entre S y W (me dijeron). El misterio es realmente el retraso de 15 minutos. Pensé que podría ser algún tipo de protección contra DDoS?

No soy experto en la red, así que pedí ayuda, pero nadie está disponible para ayudarme. Pasé 30 minutos con un chico captura de paquetes con Wireshark (anteriormente Ethereal), sino por "razones de seguridad", no puedo ver el resultado. Él tiene que analizar esto y volver a mí. Pedí los registros de cortafuegos; misma historia.

No soy root o administrador en estas cajas, ahora no sé qué hacer ... No estoy esperando una solución de ustedes, pero algunas ideas sobre cómo avanzar sería genial!

Answer 1

Si funcionó bien en su red local, entonces no preveo que esto sea una cuestión de programación (re. flush() los comentarios).

¿Es la conectividad de red entre las 2 máquinas normales de otra manera? Se puede transferir cantidades similares de datos a través de FTP (por ejemplo) sin ningún problema. Se puede reproducir este problema golpeando juntos una secuencia de comandos de cliente / servidor sólo para enviar trozos de tamaño apropiado de los datos. es decir, es la conectividad buena red entre W y S?

Otra pregunta. Ahora tiene un cortafuego entre medio. Podría ser esto un posible cuello de botella que no estaba allí antes? (No sé cómo eso explicaría el retraso 15m coherente sin embargo).

Pregunta final. ¿Cuáles son sus parámetros de configuración TCP creados para ser (tanto en W y S - Estoy pensando en los parámetros de nivel de sistema operativo). ¿Hay algo ahí que pueda sugerir o dar lugar a una cifra de 15 m.

No estoy seguro si eso sirve de ayuda.

Answer 2

Derecho. Si estás utilizando un BufferedOutputStream necesita llamar a flush () a menos que llegue el tamaño del búfer máx.

Answer 3

Además de intentar que Brian dijo, también se puede comprobar lo siguiente

1) tcpdump Ejecutar en uno cualquiera de los servidores, y ver la secuencia de flujos de mensajes desde el momento cuando un trabajo se inicia para después del retardo, cuando todo el procesamiento se ha completado. Que le dirá qué lado está causando el retraso (W o S). Compruebe si hay algún retransmisiones, acks perdidas, y así sucesivamente.

2) ¿Hay algún tipo de fragmentación pasando entre W y S?

3) ¿Cuáles son en los que se pegan las condiciones de carga de red en los servidores de los bytes? Se carga pesada causando errores en la salida, lo que resulta en las colas de socket no se vacía? (También podría haber un error de NIC, en donde después de golpear alguna condición de error, los tampones NIC no se vacían, o es incapaz de reanudar la transmisión, y tal condición está consiguiendo borran por una especie de un organismo de control)

Más información sobre los dos anteriores sería de gran ayuda.

Answer 4

¿Estás seguro que los hilos pegados en las llamadas de lectura son los mismos hilos que estaban enviando los datos? ¿Es posible que los hilos realmente involucrados en cambio se bloquearon en alguna otra actividad y su stackdump muestra otros hilos inocentes que acaba de pasar a estar haciendo toma de E / S? Ha sido un tiempo desde que trabajé con Java, pero yo recuerdo vagamente la JVM utilizando sockets para IPC.

Me gustaría examinar todo el lado de recepción para ver si uno de ellos es el receptor previsto y en su lugar haciendo otra cosa durante 15 minutos.

El hecho de que funciona en un solo lugar frente a otro por lo general apunta a un error de tiempo de aplicación, no es un problema del centro de datos.