Pour donner un aperçu rapide, j'essaie d'insérer plusieurs centaines d'enregistrements de manière asynchrone dans notre base de données à l'aide d'appels individuels dans le npm mssql. Cependant, lorsque j'utilisais une ancienne version 3.3.0 de mssql, je ne recevais parfois pas de rappel du npm. J'ai mis à jour mssql vers 4.0.4 et je ne reçois toujours pas de rappels. Je l'ai retrouvé jusqu'à ce npm.
Après processPreLoginResponse, il est envoyé à tls. Ensuite, il passe à SentTLSSSLNegotiation. Pour une raison quelconque, après quelques centaines d'enregistrements une fois arrivé ici, socketEnd est appelé. Il passe ensuite à Final, la fonction enter est appelée, cleanupConnection est appelée (sans paramètres), il efface la connexion et les minuteurs de requête, ferme la connexion, socketClose est appelé puis il tente à nouveau de passer à Final, et la fonction enter n'est pas appelé, et il semble qu'il reste là indéfiniment.
Avez-vous une idée de la raison pour laquelle socketEnd est appelé en premier lieu ou pourquoi il n'est jamais diffusé dans mon code afin que je puisse le gérer ?
jstephens7
Tous les 5 commentaires
Nous avons exactement ce problème en utilisant une base de données Azure. Nous pouvons facilement recréer le problème après environ 4 heures d'exécution d'une fonction Azure sur une minuterie de 1 seconde. Y a-t-il quelque chose que nous pouvons faire pour aider? C'est un problème énorme pour nous et nous aimerions une sorte de mise à jour sur ce problème.
landondavidson
le 2 avr. 2018
Salut @landondavidson , désolé pour la réponse tardive, ça vous dérange de partager le repo pour ce problème ?
Nous avions #574 qui résolvait l'erreur de connexion intermittente dans Azure DB, il a été publié dans la version 2.1.0 fastidieuse, la plupart des packages de regroupement de connexions utilisent une ancienne version du pilote fastidieux, pouvez-vous vérifier si votre service utilise le dernier pilote ?
Suraiya-Hameed
le 31 mai 2018
@v-suhame, nous ne voyons aucune ConnectionError. La prise se ferme juste sur nous dans le processus de connexion. Je viens de soumettre une pull request avec le correctif que nous avons mis en production au cours des deux dernières semaines. Il s'agit d'un site Web avec une charge assez lourde et l'erreur a complètement disparu avec le regroupement de connexions en réessayant la connexion après avoir été signalée.
landondavidson
le 4 juin 2018
@landondavidson @jstephens7 https://github.com/tediousjs/tedious/pull/763 a été fusionné et publié sous le nom [email protected] .
S'il vous plaît laissez-nous savoir si vous rencontrez toujours des problèmes. En attendant, je clos ce sujet. ??
arthurschreiber
le 11 juil. 2018
Le correctif de plus tôt fonctionne pour moi, mais j'ai décidé d'exécuter wireshark pour essayer de voir le trafic réseau menant à l'erreur en premier lieu. J'ai pu reproduire le problème deux fois lors de l'exécution de la trace.
Je ne suis pas sûr de la signification d'une partie de ce que j'ai récupéré, j'inclurai donc ce que j'ai remarqué en commun entre les deux fois où l'erreur s'est produite.
Les deux fois, nous avons eu un PSH ACK et un FIN ACK avec une taille de fenêtre de 66560.
Après cela, les deux fois, nous avons eu un RST ACK.
Ensuite, il semble qu'il démarrait la prochaine négociation TLS (bonjour client, bonjour serveur... message de prise de contact chiffré)
Après cela, les deux fois, il a commencé à envoyer des données d'application et nous avons reçu une "alerte cryptée" TLS suivie d'ACK et socket.end avait été appelé (plus de trafic TLS/TCP).
jstephens7
le 4 févr. 2019
Questions connexes
GuyHarwood
·
7Commentaires
diginfo
·
6Commentaires
c5soft
·
5Commentaires
tvrprasad
·
5Commentaires
aniltomar10
·
5Commentaires
Commentaire le plus utile
@landondavidson @jstephens7 https://github.com/tediousjs/tedious/pull/763 a été fusionné et publié sous le nom
[email protected].S'il vous plaît laissez-nous savoir si vous rencontrez toujours des problèmes. En attendant, je clos ce sujet. ??