[Documentation improvements] HeartBeats stops working when the tabs goes inactive on Chrome 88+

[anthonyraymond]

Hello,

I've spent an hour trying to debug a non-existing but today between your lib and a stomp server. To prevent other from doing so here is what is going on.

Problem

I have a (15,15) heartbeat set in my app. When my tab stays inactive for some time (+-5min) the Stomp connection is eventually closed for no reasons.

Reason

HeartBeats stops working after some times
In chrome (and all Chromium forks), when a tab respect some criterias it is considered inactive and all his timers are throttled.

The throttling used to be 1 action per second, but recently, with chrome 88 and above a stricter set of criterias also applies, and if they match the throttle is now one action per minute.

It's not something that can be fixed IMO, but i can be handy to have this warning in the project documentation.

[kum-deepak]

This indeed is an issue. Thanks for your detailed notes including links to appropriate documentation.

I agree that it is not fixable by this library. It is understandable why browsers are taking this approach, can't blame them 😄

However, it will be useful if we can find settings that work. I have the following thinking:

• The outgoing ping uses and relies on a block linked to the timer to be executed.
• Incoming ping, however, works differently. It uses a timer block to check if there was no ping received within a window. If the ping from the server is actually received within the window the block linked to the timer need not be executed.
• So, we might have a solution - if we disable outgoing ping (by setting the period to 0).

You should try and see if it makes a difference. Meanwhile, I will also test and see if that works.

[anthonyraymond]

Disabling outgoing ping might indeed work, relying on the server sending the heartbeat should be enough to prevent the websocket being closed.

There might be another solution (which is ugly):

• Since the receiving timer keeps working, we could send a PING as soon as we receive a PONG from the server. Most of the time incomming and outgoing uses the same HeartBeat rate. Most of the time it will solve the problemn but that makes the Api highly non-intuitive IMO....

having a 0 outgoing ping look like a way better idea to me, but it should be sepcified in the documentation.

[alana1]

We are facing the same problem even we set the outgoing to 0. We experiencing websocket disconnects around every minute. Do you have any workaround suggestions?

[anthonyraymond]

Your problem and the one describe in this issues are two différents topics, you get random disconnection every minutes or so.
This topic is about chrome shutting down timeouts and intervals when the tab goes inactive.

It would be hard to help you without any background, are you using this lib as a client or a server? what is the the STMP client / serveur you use, what parameter are you using, is there a reverse proxy in between?

[alana1]

Thank you for your response. We are using the stomp lib as a client. The root issue is actually the one reported in this topic here. As reported in this topic, when tab is inactive for ~5mins, the stomp connection is closed. As you have suggestion on March 22 to set the outgoing hearbeat to 0, we are getting ~1mins disconnects. However, we set it back to 10sec (outgoing and incoming), the stomp connection is closed when tab is inactive (as reported here). I hope that make sense.

[anthonyraymond]

i've not experimented with the HB outgoing = 0 myself. I'm an Hard believer in HeartBeat, it solves problem at multiple levels (reverse proxy closing inactive WS conn on his own, dead connection detection, and so on).

Having that said the 1min timeout seems weird, do you know which side is closing the conn? is it the server or the client?

[kum-deepak]

We are facing the same problem even we set the outgoing to 0. We experiencing websocket disconnects around every minute. Do you have any workaround suggestions?

Recent versions of RabbitMQ seem to have a bug. Which broker are you using?

[alana1]

i've not experimented with the HB outgoing = 0 myself. I'm an Hard believer in HeartBeat, it solves problem at multiple levels (reverse proxy closing inactive WS conn on his own, dead connection detection, and so on).

Having that said the 1min timeout seems weird, do you know which side is closing the conn? is it the server or the client?

Client side is closing the connection.

[alana1]

We are facing the same problem even we set the outgoing to 0. We experiencing websocket disconnects around every minute. Do you have any workaround suggestions?

Recent versions of RabbitMQ seem to have a bug. Which broker are you using?

We tested it with version 3.7.7

[kum-deepak]

In my tests it works for 3.6.x, fails for 3.7.x and 3.8.x.

I raised it the RabbitMQ user group, please see https://groups.google.com/g/rabbitmq-users/c/HKDpmrZpxkU/m/FdyZb3HoBAAJ for details.

[alana1]

Thank you for sharing the information. I did noticed that there is RabbitMQ heartbeat configuration that is default to 60s. This configuration appears to only apply to connections using AMQP protocol. I do see the hearbeat = 60 in the RMQ management UI connection information. However, I don't see heartbeat for connections with WebStomp protocols.

[rad-pat]

For info, I have managed to prevent disconnection by setting heartbeats to 60s, 60s (min time setInterval will be served by Chrome when tab is idle), but I had to increase default web socket timeout on RMQ to 120s (default is 60s) to prevent closure from server-side. web_stomp.ws_opts.idle_timeout = 120000

[kum-deepak]

Many thanks!

This indeed is interesting. I was not aware of web_stomp.ws_opts.idle_timeout option. As per the protocol, heartbeats are optional. So, setting this timeout to a very large value (say a day), should allow a connection to survive without heartbeats.

The heartbeats may still be desirable to detect a stale connection. It will be worth testing enabling only server-initiated heart beats along with a high value of web_stomp.ws_opts.idle_timeout. To be explicit no client-side heartbeats that depend on timers.

Based on the findings I will update the documents and add an FAQ entry.

[GJohannes]

Hello everyone :)
is this Issue still beeing worked on?

I still have this issue with the same setup as described above: RabbitMQ 3.7.x using the Stomp plugin, SpringBoot and Angular frontend. Only tabs that are not focused are affected.

Reconfiguring the Rabbit did nothing since the connection is restarted by the client. Server side heartbeats are received just fine. I am actually not even certain that the heartbeats are the reason for the reconnect since the reconnect happens always in 1 minute cycles even when the heartbeat frequenzy is set to serveral minutes.

[anthonyraymond]

Hello, @GJohannes this is not a bug that can be fixed, it's a Chrome wanted behaviour, we can't fight against the browser in this case.