vaadin / flow

Vaadin Flow is a Java framework binding Vaadin web components to Java. This is part of Vaadin 10+.
Apache License 2.0
616 stars 167 forks source link

Connection to backend lost after network interruption when using websockets #20213

Open lennartfricke opened 1 week ago

lennartfricke commented 1 week ago

Description of the bug

I used the vaadin gradle starter skeleton to have a minimal reproducing example and changed AppShell.java to add a push annotation

/**
 * Use the @PWA annotation make the application installable on phones, tablets
 * and some desktop browsers.
 */
@PWA(name = "Project Base for Vaadin", shortName = "Project Base")
@Theme("my-theme")
@Push(transport = Transport.WEBSOCKET, value = PushMode.AUTOMATIC)
public class AppShell implements AppShellConfigurator {
}

After starting using jettyRun. I open the app in a browser in a virtual machine (I used VirtualBox and libvirt).

I type in something and verify I get a result. I change the textbox content.

Then I virtually pull the cable.

In libvirt this can be done as follows, start virsh. Find out machine name (domain <dom>) using list, find out interface () using domiflist <dom>. 'Pull cable' using domif-setlink <dom> <iface> down.

It is not sufficient to use the developer tools. That does not interrupt the websocket connection.

Press 'Say hello' again to send something and wait some time (best reproduced when browser print something like 'Websocket closed, reason: Connection was closed abnormally (that is, with no close frame being sent). - wasClean: false')

Then reconnect the network (domif-setlink <dom> <iface> up).

And observe that nothing is send any more.

Expected behavior

The connection is reestablished and interaction is possible again.

I do not know if the last update should still be pushed or if resynchronization is better.

Minimal reproducible example

I downloaded https://github.com/vaadin/base-starter-gradle and applied the change above. I copied the code when vaadin version was 2.4.10

Versions

mcollovati commented 10 hours ago

By default, Atmosphere does not call onOpen or onReopen when the web-socket connection is re-established. As a result, if also fallback transport is WEBSOCKET, the application will not recover from the disconnected state. If Atmosphere fallbacks to LONG_POLLING (default), then onReopen is called and the app resumes to connected state.

However, in both cases, the RequestResponseTracker.hasActiveRequest() is never reset to false, thus preventing new UIDL messages from being sent to the server.