LiveQuery socket not reconnecting on resume from sleep in mobile

[dpatel20]

I have created a Web App use the Parse backend which utilises Parse's LiveQuery (Websockets).

Whilst testing on mobile devices, I have noticed that after a long(ish) sleep the LiveQuery events don't seem to get through. Best as I can tell/understand, the browser is closing (?) the websocket.

Behind the scenes, I know the Parse JS SDK implements an exponential backoff automatic reconnect.

Is there a way to instantly auto connect on the browser window getting focus?

I tried a quick hack in the JS SDK as follows in the LiveQuery 'open' function

      if (firstTime) {
        $(window).on('focus', function () {
          console.log("Window got focus");
          this.attempts = 0;
          console.log(_this4.state)
          if (_this4.state !== CLIENT_STATE.CONNECTED)
            _this4._handleReconnect();
        });
        firstTime = false;
      }

However, this does not seem to work (at least not consistently). If I remove the check on the CONNECTED status, then it seems to work but then I end up with multiple sockets open (I know as I have a toast popup that is activated on live updates -- without the CONNECT check I get two popups instead of one). So, does that suggest that the Parse SDK is not aware the connection is broken? How I can I force a check?

[dpatel20]

After debugging further, I've seen that the state is CONNECTED so I can only guess it has not yet updated its state. Javascript is running as my debug code fires on focus. I further tried doing a close and resubscribe:

_this4.socket.close();
_this4.resubscribe();

From this, I found that the close would not fire for exactly 1min (I output some timestamps to the HTML). I cannot find where this 1min timeout comes from...any ideas?

[dpatel20]

I'm using this to log my findings...hope someone can help:

• If I do nothing (i.e. keep parse.js as original), I can see that after a sleep (>10min) the readyState is OPEN. And, after ~1.5mins the LiveQuery I send is seen by the mobile browser. Is this something peculiar to WebSockets on Android browsers? If it's saying connected, then I'd expect an immediate update. (PS: I checked the Parse server logs and nothing shows a disconnect).

• If I do the close() followed by the resubscribe(), in the server logs I see the disconnect immediately when the close() is called. But the on close event is not seen browser for exactly 1min. And then the resubscribe() occurs immediately after.

[flovilmart]

I’m not sure it is related to the JS SDK itself. Perhaps there are workarounds that we could implement. Also, where lis your parse-server deployed?

[dpatel20]

I am using Back4App, Parse Server 2.7.1.

I agree, I don't think it is an issue with the SDK...I was just using the SDK to debug/hack to try to find a workaround.

[flovilmart]

Possibly also related to a seeverside connection configuration. Did you try with a pure JS websocker client without the parse JS SDK?

[dpatel20]

I have contacted back4app for some help...awaiting further feedback.

I have no idea how to test with a JS websocket client...you mean use something like socket.io to connect to the Parse server and see if I get the same issue? Could you help as to how to do this?

[dpatel20]

I'm starting to think it might be my phone or browser!!...not seen the issue on another phone and tablet.

[flovilmart]

@dpatel20 that's something to consider too :)

[dpatel20]

@flovilmart Seems to be occurring in other browsers and devices (to different extents/frequencies) --- all Android based. With the original code (without my hacks), it eventually seems to kick back into life.

Any suggestions of how I can work around this (or reduce the time to reconnect)?

[flovilmart]

I’m not sure at this point. Is there littérature around the reconnections problems, like with socketIO or else?

[dpatel20]

I have done some more testing and taken logcats on my Android phone and various debug messages added. I can see that the connection is actually closed and the reconnect mechanism kicks in. But then it sits in the 'open' (i.e. trying to re-open the socket) state as there is no network.

When I resume the device, it can take a few secs to reconnect but it does reconnect. I was testing fairly soon after unlocking and saw that it was missing the event. If I wait a few seconds and then fire the event, then all is good.

[flovilmart]

Ok, good to hear you have a proper explanation!

…

On Jun. 22, 2018, 05:37 -0400, dpatel20 ***@***.***>, wrote: I have done some more testing and taken logcats on my Android phone and various debug messages added. I can see that the connection is actually closed and the reconnect mechanism kicks in. But then it sits in the 'open' (i.e. trying to re-open the socket) state as there is no network. When I resume the device, it can take a few secs to reconnect but it does reconnect. I was testing fairly soon after unlocking and saw that it was missing the event. If I wait a few seconds and then fire the event, then all is good. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[dpatel20]

I should note that I had to reduce the backoff in generateInterval(). I changed it to be:

return Math.random() * k * 2000;

With the original setup I had a connection timeout error in the logcat.

[flovilmart]

@dpatel20 is the back off configuration worth an addition to the SDK so the issue can be worked around?