Tedious: Im Endzustand aufgehängt
Um einen schnellen Überblick zu geben, versuche ich mit einzelnen Aufrufen im mssql npm mehrere hundert Datensätze asynchron in unsere Datenbank einzufügen. Bei der Verwendung einer älteren Version 3.3.0 von mssql erhielt ich jedoch manchmal keinen Rückruf vom npm. Ich habe mssql auf 4.0.4 aktualisiert und erhalte immer noch keine Rückrufe. Ich habe es bis zu dieser npm verfolgt.
Nach processPreLoginResponse wird es an tls gesendet. Dann geht es zu SentTLSSSLNegotiation über. Aus irgendeinem Grund wird socketEnd nach einigen hundert Datensätzen aufgerufen, sobald es hier angekommen ist. Es geht dann zu Final über, die Enter-Funktion wird aufgerufen, cleanupConnection wird aufgerufen (ohne Parameter), es löscht die Verbindung und die Anforderungstimer, schließt die Verbindung, socketClose wird aufgerufen und dann versucht es erneut, zu Final zu wechseln, und die Enter-Funktion wird nicht aufgerufen, und es scheint nur auf unbestimmte Zeit dort zu hängen.
Haben Sie eine Idee, warum socketEnd überhaupt aufgerufen wird oder warum es nie in meinen Code geblasen wird, damit ich damit umgehen kann?
jstephens7
Alle 5 Kommentare
Wir haben genau dieses Problem mit einer Azure-Datenbank. Wir können das Problem nach etwa 4 Stunden Ausführung einer azurblauen Funktion mit einem 1-Sekunden-Timer problemlos wiederherstellen. Gibt es etwas, was wir tun können, um zu helfen? Dies ist ein großes Problem für uns und wir würden uns über ein Update zu diesem Thema freuen.
landondavidson
am 2. Apr. 2018
Hey @landondavidson , entschuldige die späte Antwort, kannst du das Repo für dieses Problem teilen?
Wir hatten Nr. 574, das den zeitweiligen Verbindungsfehler in Azure DB behoben hat, es wurde in langweiliger Version 2.1.0 veröffentlicht. Die meisten Verbindungspooling-Pakete verwenden eine ältere Version des langweiligen Treibers. Können Sie überprüfen, ob Ihre Abteilung den neuesten Treiber verwendet?
Suraiya-Hameed
am 31. Mai 2018
@v-suhame, wir sehen keinen ConnectionError. Die Steckdose schließt sich uns einfach beim Verbinden. Ich habe gerade eine Pull-Anfrage mit dem Fix eingereicht, den wir in den letzten zwei Wochen in Produktion genommen haben. Dies ist eine Website mit ziemlich hoher Auslastung und der Fehler ist vollständig verschwunden, da das Verbindungspooling nach der Meldung erneut versucht, die Verbindung herzustellen.
landondavidson
am 4. Juni 2018
@landondavidson @jstephens7 https://github.com/tediousjs/tedious/pull/763 wurde zusammengeführt und als [email protected] .
Bitte teilen Sie uns mit, wenn weiterhin Probleme auftreten. In der Zwischenzeit schließe ich dieses Thema. 🙇
arthurschreiber
am 11. Juli 2018
Der Fix von früher funktioniert für mich, aber ich entschied mich, Wireshark auszuführen, um zu versuchen, den Netzwerkverkehr zu sehen, der überhaupt zum Fehler führte. Ich konnte das Problem beim Ausführen des Trace zweimal reproduzieren.
Ich bin mir der Bedeutung eines Teils dessen, was ich zurückbekommen habe, nicht sicher, daher werde ich das aufnehmen, was mir zwischen den beiden Fehlern gemeinsam aufgefallen ist.
Beide Male hatten wir ein PSH ACK und FIN ACK mit einer Fenstergröße von 66560.
Danach hatten wir beide Male ein RST ACK.
Dann sieht es so aus, als würde die nächste TLS-Verhandlung gestartet (Client hallo, Server hallo... verschlüsselte Handshake-Nachricht)
Danach begann es beide Male, Anwendungsdaten zu senden und wir bekamen einen TLS "Encrypted Alert", gefolgt von ACKs und socket.end wurde aufgerufen (kein weiterer TLS/TCP-Verkehr).
jstephens7
am 4. Feb. 2019
Verwandte Themen
arthurschreiber
·
8Kommentare
tvrprasad
·
5Kommentare
ricklang
·
9Kommentare
c5soft
·
5Kommentare
ghost
·
5Kommentare
Hilfreichster Kommentar
@landondavidson @jstephens7 https://github.com/tediousjs/tedious/pull/763 wurde zusammengeführt und als
[email protected].Bitte teilen Sie uns mit, wenn weiterhin Probleme auftreten. In der Zwischenzeit schließe ich dieses Thema. 🙇