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

问题描述

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

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

 自< date>以来，客户端一直处于非活动状态并且它已经超过了50000 ms的不活动超时.停止连接. 

此后的标准过程是自动重新启动连接，但是此操作无济于事.如果/当用户重新激活页面时(例如，通过切换至标签页)，尽管SignalR连接已关闭，但一切都开始恢复活力.

经过大量调查，看来我们受到了此更改在Chrome v88中引入，其中如果严格限制计时器( setTimeout s)

• 该页面已隐藏5分钟以上
• 计时器已被链接"到服务器.5次或更多次-我假设这与递归类似，在递归中计时器会自行调用.
• 页面已静默"，30秒

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

该站点上运行的唯一其他Javascript是 jquery.signalR-2.4.1.js ，从SignalR来源来看，其中有很多 setTimeout .Chrome的更改会影响SignalR吗?也许是在临时网络问题或其他不可预测的事件后尝试以静默方式重新连接时?

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

解决方案

我们也面临着signalR(WebSockets作为传输)的问题.我们无法在实验室中复制它.客户的HAR文件和扩展的日志记录仅向我们提供了客户仅在关注了有趣的组之后才消费"的信息.在保持连接所需的默认30秒内未发送ping.因此，服务器关闭连接.我们在signalR客户端库中添加了日志，只看到ping计时器未按时触发.没错，没事.(客户端使用JavaScript，问题出现在客户网站上的chrome 87中(已经在一半的chrome用户中实现了限制- 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屋！