Metered connection timeouts

We have a client that has an issue with Connection timeout with Cuba-Platform in which they believe is due to metered connections (They are on the road and are attempting to collect data using mobile data) We have a suspicion that the reason is that there is a large amount of data requirements when hitting the site remotely thus being cut off. We also have cuba.web.pushLongPolling = true, as they are running a type of proxy which doesn’t support web socket.

Is there a way around this? i.e. can we turn up the timeout in the proxy, or do we simply tell the client to turn off the metered connection if they want to collect data whilst mobile?.

Thanks.

Hi,

Could you tell us more about the timeouts? Is it HTTP request timeouts or HTTP session gets expired?

the reason is that there is a large amount of data requirements when hitting the site remotely thus being cut off

Why do you think so?

Hi,

We think this is the reason as when you turn metered connection off it works just fine, our hunch is metered connections might be either automatically killing the connection at a different timeout period to save bandwidth or something else is going on. We haven’t really dug into the issue yet in case you have already encountered this issue and there is an easy fix.

Thanks.

You can disable WebSocket / Long Polling using cuba.web.pushEnabled application property. But in this case BackgroundTask functionality will not work, if you do not use it - it will not affect your application.

I’ve dug into the issue more. Metered connections are not the issue I’ve setup a test for it and had no issues. However hitting the client server I get the connection issue reasonably quickly regardless of setup. This is what I see in Chrome console window.

Tue Jun 26 08:50:59 GMT-700 2018 com.vaadin.client.communication.AtmospherePushConnection
INFO: Received push (long-polling) message: for(;;);[{"changes":{},"resources":{},"locales":{},"meta":{"appError":{"caption":"Session expired","url":null,"message":"Pay attention to any unsaved data,  and <u>click here</u> to continue.","details":null}},"syncId":-1}]

com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:9159 Tue Jun 26 08:50:59 GMT-700 2018 com.vaadin.client.communication.MessageHandler
SEVERE: Response didn't contain a server id. Please verify that the server is up-to-date and that the response data has not been modified in transmission.

vEb @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:9159
K_f @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:8460
J_f @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:5464
P_f @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:4880
T_f @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:3426
hqc @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:8893
QDd @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:9169
(anonymous) @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:8788
Si @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:3920
Vi @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:7884
(anonymous) @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:5592
_f @ vaadinPush.debug.js?v2017_10_17_14_47:2761
_invokeFunction @ vaadinPush.debug.js?v2017_10_17_14_47:2750
_invokeCallback @ vaadinPush.debug.js?v2017_10_17_14_47:2880
ajaxRequest.onreadystatechange @ vaadinPush.debug.js?v2017_10_17_14_47:2104


Tue Jun 26 08:50:59 GMT-700 2018 com.vaadin.client.communication.MessageSender
SEVERE: No active request
vEb @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:9159
K_f @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:8460
J_f @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:5464
P_f @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:4880
T_f @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:3426
IGd @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:7760
eqc @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:3140
nGd @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:9104
gqc @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:9112
hqc @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:8893
QDd @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:9169
(anonymous) @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:8788
Si @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:3920
Vi @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:7884
(anonymous) @ com.haulmont.charts.web.toolkit.ui.ChartsWidgetSet-0.js:5592
_f @ vaadinPush.debug.js?v2017_10_17_14_47:2761
_invokeFunction @ vaadinPush.debug.js?v2017_10_17_14_47:2750
_invokeCallback @ vaadinPush.debug.js?v2017_10_17_14_47:2880
ajaxRequest.onreadystatechange @ vaadinPush.debug.js?v2017_10_17_14_47:2104

Is there a possibility of them blocking the vaadin push (I’m guessing this is some type of heartbeat) and if so is there a particular port that this push requires open?

Thanks.

Probably, you are using proxy or something in the middle that cuts push id. If you switch off push or enable explicit fallback to long polling it should not occur.