CODEWITHSUNDEEP
javascriptgoogle-chromewebsocketweb-applicationssettimeout
Andrew
Andrew

Reputation: 361

Chrome timers throttling and @microsoft/signalr issue

Accordingly blogpost from Jake Archibald, from Chrome 88 implements 3 stages of throttling

Accordingly throttling implementation from Chrome 57

There are a number of automatic exemptions from this throttling:

Applications playing audio are considered foreground and aren’t throttled.

Applications with real-time connections (WebSockets and WebRTC), to avoid closing these connections by timeout. The run-timers-once-a-second rule is still applied in these cases.

Second cite imeratively says, that once application has Websocket connection, application exempt from throttling.

The fact is, we use @microsoft/signalr library as top-level api for websocket connections, and this library uses internal ping (not a ping opcodes) messages, wrapped with setTimeout. After 5 minutes of background work, that timer throtlled and stops sending ping messages, thats leads to close event and websocket connection being closed.

I'm asking for more detailed explanation:

Does Chorome 88 enbles throttling for applications, that have real-time connections?

Does timers will be throttled regardless websocket connection appeareance and only websocket instances exempt from throttling?

Upvotes: 0

Views: 804

Answers (1)

Andrew
Andrew

Reputation: 361

accordingly this post same issues reported.

Quick explanation is: As Jake wrote in blogpost about heavy throttling

the browser will check timers in this group once per minute. Similar to before, this means timers will batch together in these minute-by-minute checks.

That is! After 5 minutes tab spent in background, signalr ping algorithm will be throttled to 1 minute, BUT default values for keepAliveIntervalInMilliseconds = 15sec and serverTimeoutInMilliseconds = 30sec, thats twice smaller than heavy throttling timer delaying time and for server side it is count as ping failure that is predicate for lifetime methods invocation and stopping the connection, but first, server side trying to stop connection with disconnect handshake, and physically client is still connected, the result is - CloseEvent with code 1000 and wasClean = true. This behaviour wount produce any errors.

Front-end clients must update version of @microsoft/signalr to >= 5.0.6 to solve this problem. Changes

Upvotes: 0

Related Questions