Para dar uma visão geral rápida, estou tentando inserir várias centenas de registros de forma assíncrona em nosso banco de dados usando chamadas individuais no mssql npm. No entanto, ao usar uma versão anterior 3.3.0 do mssql, às vezes eu não recebia um retorno de chamada do npm. Atualizei o mssql para 4.0.4 e ainda não estou recebendo retornos de chamada. Eu rastreei até este npm.
Após processPreLoginResponse, ele é enviado para tls. Em seguida, ele faz a transição para SentTLSSSLNegotiation. Por alguma razão, depois de algumas centenas de registros, uma vez que ele chega aqui, socketEnd é chamado. Em seguida, faz a transição para Final, a função enter é chamada, cleanupConnection é chamada (sem parâmetros), limpa a conexão e solicita temporizadores, fecha a conexão, socketClose é chamado e, em seguida, tenta fazer a transição para Final novamente e a função enter não é chamado e parece ficar lá indefinidamente.
Alguma ideia de por que socketEnd é chamado em primeiro lugar ou por que nunca foi adicionado ao meu código para que eu pudesse lidar com isso?
jstephens7
Todos 5 comentários
Estamos tendo exatamente esse problema ao usar um banco de dados azure. Podemos recriar facilmente o problema após cerca de 4 horas de execução de uma função azure em um temporizador de 1 segundo. Podemos fazer algo para ajudar? Este é um grande problema para nós e adoraríamos algum tipo de atualização sobre o assunto.
landondavidson
em 2 abr. 2018
Olá @landondavidson , desculpe pela resposta tardia. Você se importa em compartilhar o repositório para este problema?
Tivemos # 574 que abordou ConnectionError intermitente no Azure DB, foi lançado na tediosa v2.1.0, a maioria dos pacotes de pool de conexão estão usando uma versão mais antiga do driver tedioso, você pode verificar se seu dep está usando o driver mais recente?
Suraiya-Hameed
em 31 mai. 2018
@ v-suhame, não estamos vendo nenhum ConnectionError. O soquete simplesmente fecha sobre nós no processo de conexão. Acabei de enviar uma solicitação de pull com a correção que colocamos em produção nas últimas duas semanas. Este é um site com uma carga muito pesada e o erro desapareceu completamente com o pool de conexão tentando a conexão novamente após ser relatado.
landondavidson
em 4 jun. 2018
@landondavidson @ jstephens7 https://github.com/tediousjs/tedious/pull/763 foi mesclado e lançado como [email protected] .
Informe-nos se ainda estiver tendo problemas. Enquanto isso, encerrarei este problema. 🙇
arthurschreiber
em 11 jul. 2018
A correção anterior está funcionando para mim, mas decidi executar o WireShark para tentar ver o tráfego de rede que leva ao erro em primeiro lugar. Consegui reproduzir o problema duas vezes durante a execução do rastreamento.
Não tenho certeza do significado de qualquer parte do que recebi, então vou incluir o que percebi em comum entre as duas vezes em que o erro ocorreu.
Ambas as vezes tivemos um PSH ACK e FIN ACK com um tamanho de janela de 66560.
Depois disso, nas duas vezes tivemos um RST ACK.
Em seguida, parece que estava iniciando a próxima negociação TLS (hello do cliente, hello do servidor ... mensagem de handshake criptografada)
Depois disso, nas duas vezes, ele começou a enviar dados do aplicativo e recebemos um "alerta criptografado" TLS seguido por ACKs e socket.end foi chamado (sem tráfego TLS / TCP adicional).
jstephens7
em 4 fev. 2019
Questões relacionadas
ghost
·
5Comentários
c5soft
·
5Comentários
diginfo
·
6Comentários
anthonylau
·
8Comentários
David-Engel
·
5Comentários
Comentários muito úteis
@landondavidson @ jstephens7 https://github.com/tediousjs/tedious/pull/763 foi mesclado e lançado como
[email protected].Informe-nos se ainda estiver tendo problemas. Enquanto isso, encerrarei este problema. 🙇