自 Chrome 88 以来的 SignalR 和/或计时器问题 [英] SignalR and/or timer issues since Chrome 88

问题描述

我们有一个 ASP.Net WebForms 应用程序，它使用 SignalR (v2.4.1) 在服务器和客户端之间进行一些双向通信.多年来一直运行良好:连接稳定，有数百名用户使用它等.

但是，我们已经开始从我们的客户群中收到有关连接问题的零星报告，所有报告都报告相同的事情:如果浏览器 (Chrome) 会话闲置超过 5 分钟，连接会在后台断开.页面中的所有计时器停止定期运行，这(除其他外)停止保持"停止发送，最终连接失败并出现客户端错误:

客户端自<日期>以来一直处于非活动状态.它已超过 50000 毫秒的不活动超时.停止连接.

此后的标准程序是自动重新启动连接，但这不会做任何事情.如果/当用户重新激活页面(例如通过切换到选项卡)，一切都会开始恢复活力，尽管 SignalR 连接已关闭.

经过大量调查，我们似乎受到了的影响此更改在 Chrome v88 中引入，其中计时器 (setTimeouts) 受到严格限制，如果

• 页面已隐藏超过 5 分钟
• 计时器已被链接"5 次或更多次 - 我假设这类似于递归，定时器调用自身.
• 页面已静音"；30 秒

5 分钟/30 秒的条件与我们收到的报告相符.但是，我们在我们的页面上运行非常基本的 Javascript:在我们自己的代码中只有两种 setTimeout 用法，这两种用法都不能链接"；(递归)到自己身上.我们也无法复制这个问题:它在我们的测试中发生过，但我们无法使其可靠地发生.通过 chrome://flags/#integrated-wake-up-throttling 禁用此功能似乎可以缓解该问题 - 但当然，我们不能将其作为使用我们网站的要求.>

网站上唯一运行的其他 Javascript 是 jquery.signalR-2.4.1.js，并且从 SignalR 源代码来看，那里有很多 setTimeout.SignalR 是否会受到 Chrome 中这一变化的影响；也许是在临时网络问题或其他一些不可预测的事件后尝试以静默方式重新连接时?

如果没有，是否有任何方法可以在任何浏览器或 IDE 中跟踪已启动的计时器(更重要的是链接")，以便我们了解可能触发此限制的原因?

解决方案

我们也面临着 SignalR(WebSockets 作为传输)的问题.我们无法在实验室中重现它.我们客户的 HAR 文件和扩展日志仅向我们提供了客户仅在关注感兴趣的群组后才消费"的信息.在保持连接所需的默认 30 秒内不发送 ping.因此服务器关闭连接.我们在 signalR 客户端库中添加了日志，只看到 ping 计时器没有按时命中.没有错误，没有什么.(客户端是 JavaScript，问题发生在 chrome 87 的客户站点上(已经为一半的 chrome 用户实施了限制 - https://support.google.com/chrome/a/answer/7679408#87))

世界正在慢慢意识到一个问题":https://github.com/SignalR/SignalR/issues/4536

我们为客户提供的快速帮助是从服务器站点创建一个具有手动广播乒乓机制的 ET，每个客户都必须回答.避免依赖于 signalR 库中的 JavaScript ping，直到更好的"提供了解决方案或修复.

We have an ASP.Net WebForms application that uses SignalR (v2.4.1) to do some bi-directional communications between server and client. It's worked fine for years: connections are stable, hundreds of users use it, etc.

However, we've started to get sporadic reports of connection problems from across our client base, all reporting the same thing: if the browser (Chrome) session goes idle for more than 5 minutes, the connection drops in the background. All timers in the page stop being run regularly, which (amongst other things) stops "keepalives" stop being sent, and eventually the connection fails with the client-side error:

The client has been inactive since <date> and it has exceeded the inactivity timeout of 50000 ms. Stopping the connection.

Standard procedure after this would be to automatically restart the connection, but this doesn't do anything. If/when the user reactivates the page (e.g. by switching to the tab), everything starts to spring back into life, albeit with a closed SignalR connection.

After much investigation, it seems that we're being impacted by this change introduced in Chrome v88, where timers (setTimeouts) are severely restricted if

• The page has been hidden for more than 5 minutes
• The timer has been "chained" 5 or more times - I'm assuming this is similar to recursion, where the timer calls itself.
• Page has been "silent" for 30 seconds

The 5 minutes/30 seconds condition fits with the reports we're getting. However, we're running pretty basic Javascript on our page: there are only two uses of setTimeout in our own code, neither of which could ever "chain" (recurse) onto themselves. We also cannot replicate the issue: it's happened to us in testing, but we can't make it happen reliably. Disabling this feature via chrome://flags/#intensive-wake-up-throttling seems to mitigate the issue - but of course, we can't make this a requirement to use our site.

The only other Javascript running on the site is jquery.signalR-2.4.1.js, and from the SignalR source, there are lots of setTimeouts in there. Could SignalR be impacted by this change in Chrome; perhaps when it tries to silently reconnect after a temporary network issue or some other unpredictable event?

If not, is there any way, in any browser or IDE, to track which timers have been launched (and, more importantly, "chained"), so we can see what could be triggering this restriction?

解决方案

We're as well facing issues with our signalR (WebSockets as transport). We're not able to reproduce it in our lab. The HAR files of our customer and extended logging provided us only the information that the client "consuming only after following interesting groups" is not sending pings within the default 30 seconds needed to keep the connection. Therefore the server closes the connection. We added logs in the signalR client library and only saw the ping timer not being hit on time. No error, no nothing. (Client is JavaScript and the issue occurred on customer site in chrome 87 (throttling was implemented there already for half of the chrome users - https://support.google.com/chrome/a/answer/7679408#87))

And the world is slowly getting aware of "an issue": https://github.com/SignalR/SignalR/issues/4536

Our quick help for our customers will be to create an ET with a manual broadcast ping-pong mechanism from the server site and each client will have to answer. Avoiding being dependent on the JavaScript ping in the signalR library until a "better" solution or fix is provided.

这篇关于自 Chrome 88 以来的 SignalR 和/或计时器问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！