0

Because of a frequent losing of websoket connection between client and server, is this a good idea to use Vaadin 23 WEBSOCKET_XHR + ui.setPollInterval() as a backup channel?

For example:

var ui = UI.getCurrent();
ui.setPollInterval(500);
listenableFuture.addCallback(result -> {
    ui.access(() -> {

    // some ui updates

    ui.setPollInterval(-1);
    ui.push();

});

Theoretically, in case the push will not deliver changes to the client, the client will pull the changes via XHR call. Does such setup make sense?

alexanoid
  • 24,051
  • 54
  • 210
  • 410

1 Answers1

0

It seems a bit pointless to me.

If you're using polling, there's no sense in using ui.push(), as Server Push is only needed when there is no request from the client. With polling enabled, the client sends requests periodically (in your case, every 500 milliseconds after the arrival of the last response). So you're getting no benefit from the actual Server Push as the client is polling the server every 0.5 seconds already.

ollitietavainen
  • 3,900
  • 13
  • 30
  • Thanks for your answer. The biggest issue with Vaadin Push - it sometimes works unstable on mobile devices. With the approach described in my question, I think about the following - Push typically in my case works faster than 500ms. This is a preferable communication channel. In such case response with UIDL will be returned faster than polling and thus - the polling will not start (`setPollInterval(-1)`), but in case push fails, then polling will do the job via XHR. Polling here is just a “backup channel”. Will it work in such case? – alexanoid Nov 24 '22 at 13:53
  • I _think_ you'll still send a single poll message before the new configuration gets updated by the push. And even if it would work in an optimal scenario, you need to consider the case where the server is under some load spike; if the server doesn't respond with a push fast enough, that means polling will continue to increase the load, which in turn makes the situation worse. LONG_POLLING Push configuration sounds like a much simpler solution to your issue (or if you really need websockets, then you should look into implementing a custom Push transport with Atmosphere) – ollitietavainen Nov 25 '22 at 07:41