um cenario deste, o generalista, profissional desejado por diversas organizacoes, nao fara diferenca. Pois serao erros, alertas e incidentes de tecnologias especificas, para estes casos somente o especialista sera valioso e podera dar uma resposta imediata. Nos preocupa quando nos deparamos com profissionais focados em inovacao, por exemplo, que sequer tem uma boa base de rede e sistema operacional. E o profissional de middleware? Bem, este com uma base boa, conforme mencionado acima, sempre tera lugar quando todos fogem, quando escalar nao resolve o problema, e quando resolve utiliza-se a um alto custo por aplicacoes e configuracoes ma dimensionadas, sejam em uma infraestrutura publica ou privada. O mercado exigira do profissional de middleware uma boa adaptacao as novas tecnologias e linguagens emergentes, mas assim como o administrador de banco de dados, nao sera nestes 10 ou 20 anos que ele vera o seu fim. Pois onde houver um servidor de aplicacao como backend, um webserver como frontend, um cache ou balanceador de carga, existira a necessidade de um profissional de middleware. Entenda que ser um especialista em middleware, nao faz de voces ignorantes em outras areas, mas especialistas atentos as inovacoes e que tem ciencia das novas funcionalidades disponiveis no mercado.Vamos entao ao detalhamento tecnico do problema com o KeepAlive? Unindo os relatos dos usuarios e desenvolvedores que mencionaram que apos clicar duas vezes no mesmo item do sistema o mesmo pendurava, avaliamos quais logs poderiam nos apoiar no Apache e nao identificamos informacoes relevantes, ainda que tenhamos passado a severidade do log dos modulos e core do Apache para debug. O sintoma observado neste momento eram as conexoes presas gerando WAIT nos servers do Apache, ate o momento na versao 2.2 utilizando como MPM o Worker. Apos nos analisamos os logs dos containers Java, que processavam as requisicoes vindas do webserver tanto pelo sistema quanto para a API, comecamos a evoluir, pois os managedservers* nos davam mais informacoes:<20 17h57min17s="" brt=""> <[ServletContext@448764570[app:app module:app path:null spec-version:3.0]] Root cause of ServletException.org.springframework.web.client.ResourceAccessException: I/O error on POST request for "http://192.168.1.245:85/api/rest/publico/usuarioCliente/findUsuarioById":Response had end of stream after 0 bytes; nested exception is java.io.EOFException: Response had end of stream after 0 bytes Diante do cenario presente, buscamos apos a analise o isolamento de componentes afetados, iniciando o isolamento por arquitetura, apos solucoes tecnologicas e por fim seus modulos. Iniciamos os trabalhos em um ambiente controlado e sem concorrencia onde a simulacao foi viavel, com backups realizados para que pudessemos voltar ao marco 0. Primeiramente eliminamos possiveis causas como rede, ajustes de sistema operacional e parametrizacao de Sysctl e Limits. Outro item isolado foi a criacao de novos VirtualHosts, com novas portas, porque os atuais estavam usando outro modulo que gostariamos de isolar do problema que era o rewrite_module*. Apos atualizamos a versao do Apache 2.2 para 2.4, sem sucesso na operacao alternamos entre modulos MPM disponiveis, atualizacao do modulo de integracao com o Weblogic, por fim substituicao pelo ModProxy. Como tentativa de eliminacao substituimos o Apache por Nginx. Nenhuma alteracao surtiu efeito a ponto de eliminar os sintomas.Trabalhar em equipe nao e apenas trabalhar em conjunto e preciso compartilhamento.