Atualmente estou investigando conexões de longa duração de um aplicativo da Web baseado em Java / Tomcat. Depois de excluir qualquer motivo interno ou baseado em aplicativo, estou agora na camada de rede. A razão pela qual estou investigando esse problema é que temos picos aparentemente aleatórios em nosso monitoramento do tempo de resposta. Ao investigar, descobri que esse comportamento não é tão aleatório, mas acionado por determinadas Solicitações de HTTP do cliente. A coisa especial sobre essas conexões é que todas elas se originam do mesmo endereço IP e parecem usar um Bluecoat Proxy, porque eu vejo um cabeçalho HTTP x-bluecoat-via.
Como eu disse, o aplicativo em si executa normalmente, apenas o final da conexão (do ponto de vista do Tomcat) parece estar de alguma forma atrasado. O servidor não fala diretamente com o cliente, mas está atrás de um Loadbalancer F5 que deve armazenar as respostas em cache (o que pode não acontecer devido a um cabeçalho de identidade de codificação de aceitação e à resposta real sendo grande para o buffer).
Eu tenho um dump TCP, devido a um erro infeliz atualmente eu só vejo pacotes do LB para o appserver, não os pacotes reais enviados do appserver.
O dump contém várias solicitações na mesma conexão TCP / IP, o que é devido ao pool de conexões feito pelo F5. A última solicitação HTTP nesta conexão é a conexão real que foi sinalizada como longa duração (925836.442ms) em nosso registro. O que eu vejo são os pacotes de requisição, uma série de ACKs que me levam a acreditar que o appserver está escrevendo sua resposta e finalmente dois pacotes FIN, ACK seguidos por um RST, ACK que é o último pacote enviado pelo F5.
De um ponto de vista de tempo tudo isso acontece no decorrer de 250ms, o último pacote é enviar 15 Minutos e 13 Segundos antes de ver o log de resposta no appserver que é escrito após a resposta ser concluída pelo Tomcat .
Estou meio que fora do Ideas no momento e tenho algumas perguntas abertas:
Existe algum motivo para o Linux manter uma conexão aberta que tenha recebido um RST e não informar a camada de aplicação?
Existe algum outro tempo limite que possa levar a esse comportamento? Se esse fosse o tempo limite de retransmissão TCP, eu veria mais RSTs do LB.
Alguma outra ideia de por que uma conexão fechada no fio levaria a uma conexão ainda aberta na camada de aplicação?
Como algo que acontece na camada de aplicação (solicitação HTTP especial) leva a um comportamento reproduzível na camada de transporte?
Talvez eu esteja completamente errado e esse é um problema de manutenção de conexão dentro do Tomcat?
Eu não posso realmente ajudar na camada de rede, mas no Tomcat existem vários lugares onde você pode configurar esse link . Você pode tentar substituir o tempo limite e configurá-lo para fechar a conexão após um determinado período de tempo.
No link, você também tem configurações de balanceador de carga que podem ser úteis em seu cenário.
Tags networking java tomcat linux tcp