Resynchronizing UI by client's request.

[joliebig]

Description of the bug / feature

We are running a cloud-application using vaadin. After application start (Java, SpringBoot application) a warning appears in the application's log:
c.v.f.s.c.ServerRpcHandler Resynchronizing UI by clien'ts request...

The application itself seems to hang (progressbar appears in the browser) and nothing is shown. Requesting a different location/route from the same Vaadin application works fine at the log message above usually does not appear anymore.

The problem appears so far only in the following setup and cannot be reproduced locally, i.e., running only the Vaadin application.

  Internet                     private Cloud
                       +
                       |
                       |
                       |    +----------------------+    +---------------------+
                       |    |                      |    |                     |
    +------------>     |    | ReverseProxy (nginx) +--->+ Vaadin Application  |
                       |    |                      |    |                     |
                       |    +----------------------+    +---------------------+
                       |
                       |
                       |
                       |
                       +

Minimal reproducible example

I cannot share the code or a setup I'm afraid.

Expected behavior

No log file entry and a successfully running application.

Actual behavior

see above.

Versions:

- Vaadin / Flow version: 18.05
- Java version: 11
- OS version: Linux 4.4.0-197-generic (Ubuntu 16.04.7 LTS)
- Browser version (if applicable):
- Application Server (if applicable): Apache Tomcat/9.0.41
- IDE (if applicable):

[TatuLund]

Some further details are needed before it can be determined if this is bug or not.

• Do you have more than one server behind nginx ?

• Do you use Push? (I assume yes)

• Which Push transport mode ?

• If you use full websocket connection, have you configured nginx accordingly ?

• Have you configured proxy timeout nginx to be long enough, so that it does not disconnect Push connection prematurely ?

[joliebig]

Hi. Thanks for the fast response.

1. Do you have more than one server behind nginx? -> Yes, but the Vaadin Application is only deployed with a single replica and appart from the description above the application is stable and not rescheduled/deployed in any form.
2. Do you use Push? (I assume yes) -> Yes.
3. Which Push transport mode? We use @Push(PushMode.AUTOMATIC).
4. If you use full websocket connection, have you configured nginx accordingly? We have some configuration, but I'm not sure that it is specific to Vaadin. Can You point me to any documentation/tutorial regarding that?
5. Have you configured proxy timeout nginx to be long enough, so that it does not disconnect Push connection prematurely? With respect to nginx we only configured proxy_read_timeout 3600s; so far.

[TatuLund]

Yes, but the Vaadin Application is only deployed with a single replica and appart from the description above the application is stable and not rescheduled/deployed in any form.

Ok. This is easier. If you in future deploy Vaadin app in multiple nodes, remember to configure sticky sessions.

Which Push transport mode? We use @Push(PushMode.AUTOMATIC).

This means you do not explicitly define transport mode, so you use the default which WebSocket_XHR. This is easier, as the connection from browser to server is still http and you do not need to configure webscoket support in nginx. Server is pushing to browser is websockets. Each message sent by server has sequence number. If Vaadin client in browser observers that sequence number is skipped, it will ask to resynchronize, because server - client state can be inconsistent due lost message. The most natural reason for this is an issue with network connection. That can be in proxy configuration, it can be flaky wifi, slowness in vpn packet sniffer processing leading to messages to arrive in browser in inconsistent order. I.e. there are many possibilities.

[joliebig]

Hi, thanks for the update. Closing the issue, since our problem is most likely not a problem.