O que causa fios de suspensão misteriosos em colfusão -> comunicação MySQL

Question

Um dos "recursos" mais interessantes do ColdFusion é como lida com solicitações externas. A essência básica é que, quando uma consulta é feita para uma fonte externa através <cfquery> ou ou qualquer outra solicitação externa como esse ele passa a solicitação externa para um driver específico e, nesse ponto, o próprio CF não pode suspendê -lo. Mesmo que um tempo limite seja especificado na consulta ou no CFSetting, ela é clara ignorada para todas as solicitações externas.

http://www.coldfusionmuse.com/index.cfm/2009/6/9/killing.threads

Portanto, com isso em mente, o problema que encontramos é que, de alguma forma, a comunicação entre nosso servidor CF e nosso servidor MySQL às vezes dá errado e deixa para trás threads hung. Eles têm as seguintes características.

1. O fio Hung aparece no CF e não pode ser morto do FusionReactor.
2. Há não Hung Thread visível no MySQL, e nenhuma consulta ativa de corrida (apenas o habitual dorme).
3. O banco de dados está respondendo a outras chamadas e parece estar operando corretamente.
4. As conexões máximas não foram alcançadas para o banco de dados nem o usuário.

Parece -me que o único candidato provável é que, de alguma forma, o CF está fazendo uma solicitação, o MySQL está respondendo a essa solicitação, mas com uma resposta que a CF ignora e continua mantendo o tópico aberto esperando uma resposta do MySQL. Isso explicaria por que o banco de dados parece não mostrar sinais de problemas, mas o CF mantém um fio aberto esperando a resposta misteriosa.

Usualmente Esses tópicos de Hung aparecem aleatoriamente em scripts de trabalho (como publicar um comentário em um artigo de notícias). Mesmo enquanto um thread é pendurado para esse script, outras solicitações para esse script passarão, o que implicaria que o script não é necessário, mas a condição enfrentada quando o script foi executada.

Executamos algum teste para determinar que não foi um erro de max_connections gerado pelo MySQL ... criamos um usuário, demos 1 conexões máximas, vinculamos essa conexão com uma consulta de sono (1000) e executamos outra consulta. Infelizmente, errou corretamente sem gerar um fio pendurado.

Então, eu fico neste momento com absolutamente nenhuma idéia do que está dando errado. Existe algum outro limite de conexão ou tempo limite que possa estar fazendo com que a comunicação entre os servidores dê errado?

Answer 1

Para encurtar a história, mas acredito que o causado foi devido ao processamento da imagem CF8 da Coldfusion. Era apenas buggy e agora no CF9 nunca mais vi esse problema.

Answer 2

Uma das coisas que você deve começar a olhar é o hardware entre os dois servidores. É possível que você tenha um roteador ou ponte ou NIC que esteja lançando pacotes ocasionais. Isso pode resultar na caixa MySQL pensando que concluiu a tarefa enquanto o servidor CF fica lá e aguarda uma resposta completa indefinidamente, criando um thread Hung.

O 3COM tem alguns detalhes sobre o teste para perda de pacotes aqui: http://support.3com.com/infodeli/tools/netmgt/tncsunix/product/091500/c11ploss.htm#22128

Answer 3

Tivemos um problema semelhante com um MS SQL Server. Lá, a causa raiz era um problema conhecido no qual, por algum motivo, o servidor acha que está desligando e o thread está pendurado (mesmo que o servidor esteja, obviamente, não desligando).

Não fomos capazes de eliminar o problema, mas conseguimos reduzi -lo desligando as conexões de banco de dados agrupadas e mexendo na taxa de atualização da conexão. (Acho que acertei esse rótulo - nenhum acesso ao administrador no meu novo emprego.) Ambos estão nas propriedades de conexão no administrador.

Apenas uma nota: o problema não é inteiramente com a CF. Aparentemente, o problema afeta todos os aplicativos Java. O que, de forma alguma, não reduz o quão irritado eu fico com isso.