为了快速概述，我尝试使用 mssql npm 中的单独调用将数百条记录异步插入到我们的数据库中。 但是，在使用旧版本 3.3.0 的 mssql 时，我有时无法从 npm 收到回调。 我将 mssql 更新到 4.0.4，但仍然没有收到回调。 我追踪到这个 npm。
在 processPreLoginResponse 之后，它被发送到 tls。 然后它转换到 SentTLSSSLNegotiation。 出于某种原因，一旦到达这里，经过几百条记录后，就会调用 socketEnd。 然后它转换到 Final，调用 enter 函数，调用 cleanupConnection（不带参数），它清除连接和请求计时器，关闭连接，调用 socketClose 然后它尝试再次转换到 Final，以及 enter 函数没有被调用，它似乎只是无限期地挂在那里。
关于为什么首先调用 socketEnd 或者为什么它从来没有冒泡到我的代码中以便我可以处理它的任何想法？
jstephens7
所有5条评论
我们在使用 azure 数据库时遇到了这个确切的问题。 在 1 秒计时器上运行 azure 函数大约 4 小时后，我们可以轻松重现该问题。 有什么我们可以帮忙的吗？ 这对我们来说是一个巨大的问题，我们希望对此问题进行某种更新。
landondavidson
于 2018-04-02
嘿@landondavidson ，抱歉回复晚了，你介意分享这个问题的回购吗？
我们有 #574 解决了 Azure DB 中的间歇性连接错误，它是在乏味的 v2.1.0 中发布的，大多数连接池包都使用旧版本的乏味驱动程序，您能验证您的 dep 是否使用最新的驱动程序吗？
Suraiya-Hameed
于 2018-05-31
@v-suhame，我们没有看到任何 ConnectionError。 套接字只是在连接过程中对我们关闭。 我刚刚提交了一个拉取请求，其中包含我们在过去两周投入生产的修复程序。 这是一个负载非常重的网站，错误已完全消失，连接池在报告后重试连接。
landondavidson
于 2018-06-04
@landondavidson @jstephens7 https://github.com/tediousjs/tedious/pull/763被合并并作为[email protected] 。
如果您仍然遇到任何问题，请告诉我们。 同时，我会关闭这个 issue。 🙇
arthurschreiber
于 2018-07-11
之前的修复对我有用，但我决定首先运行 wireshark 来尝试查看导致错误的网络流量。 在运行跟踪时，我能够两次重现该问题。
我不确定我返回的任何部分的重要性，因此我将包括我在两次错误发生之间注意到的共同点。
两次我们都有一个窗口大小为 66560 的 PSH ACK 和 FIN ACK。
在那之后，两次我们都有一个 RST ACK。
然后看起来它正在开始下一个TLS协商（客户端你好，服务器你好......加密的握手消息）
在那之后，两次它都开始发送应用程序数据，我们得到了一个 TLS“加密警报”，然后是 ACK 和 socket.end 已被调用（没有进一步的 TLS/TCP 流量）。
jstephens7
于 2019-02-04
相关问题
ggazulla
·
4评论
David-Engel
·
5评论
yosserO
·
4评论
tvrprasad
·
6评论
ricklang
·
9评论
最有用的评论
@landondavidson @jstephens7 https://github.com/tediousjs/tedious/pull/763被合并并作为
[email protected]。如果您仍然遇到任何问题，请告诉我们。 同时，我会关闭这个 issue。 🙇