No 'server connection lost' message with long-polling push

[vaadin-bot]

Originally by mpilone

---

When using long-polling push with no polling configured in the UI, the 'server connection lost' message is not displayed on the client side when the connection to the server is dropped.

This was tested using an application that only configures push and does not set a polling interval in the UI. The client machine was then disconnected from the network (removed the network cable). The client was not alerted that the connection to the server is down (the message in the upper right by default). If a polling interval is enabled, the client does get the message after a failed polling attempt.

It is clear that the client side push connection gets dropped and it tries to reconnect repeatedly so it seems like it has the information to know that the server connection was dropped. For long running push applications, it would be very useful to display when the connection is dropped so the client is aware that it will no longer get updates from the server until it resolves the issue.

This is similar to my other issue https://dev.vaadin.com/ticket/19822 where polling must be enabled as a workaround even for an all push driven application. The polling interval must be small enough to trigger the connection notification even if polling isn't desired.

---

Imported from https://dev.vaadin.com/ issue #19841

[vaadin-bot]

Originally by mpilone

---

Attachment added: Safari_Developer_Tools_Network_Traffic.png (134.0 KiB) https://trac-attachments.vaadin.com/trac/19841/Safari_Developer_Tools_Network_Traffic.png

[vaadin-bot]

Originally by proaccountapp

---

Updated prioritization date.

[vaadin-bot]

Originally by @Artur-

---

This is by design in DefaultConnectionStateHandler: https://github.com/vaadin/vaadin/blob/master/client/src/main/java/com/vaadin/client/communication/DefaultConnectionStateHandler.java#L551. You can override it in your on ConnectionStateHandler if you wish.

If there is a proxy in between, there is no way of knowing if the long polling (or streaming) connection is actually connected or not. Therefore the push connection state is used for the reconnect logic only if you are using websockets, which provides (almost) reliable connection info.

If you try to do something in the application, e.g. click a button, you will see the reconnect dialog as the events do not reach the server.

[vaadin-bot]

Originally by mpilone

---

I'm not sure I completely understand. If a client side proxy drops the push connection and the client is unable to reopen the push connection, shouldn't they be warned that they may not receive updates from the server? I could understand that the client doesn't know if the proxy to server connection is broken, but it should know if the client to proxy connection is working.

For example, if you have client -- 1 -- > proxy -- 2 --> server, any failure to connect at 1 should result in a connection lost message while any failure at 2 may not be detected by the client.

Maybe I'm misunderstanding the purpose of not displaying the connection lost message when the client can't establish a new push connection.

[vaadin-bot]

Originally by @Artur-

---

The problem is when you have client -> buffering proxy -> server and the proxy does not let response headers through before the server also sends the body i.e. pushes a message. In this case the client is in a constant "I do not know if the push channel is connected" state until suddenly the server pushes and the clients receives the message. Then a new connection is opened and the same scenario is repeated.

From the clients point of view, this looks exactly like there is a huge delay in connecting to the server. Additionally the proxy typically has a timeout and disconnects at given intervals, leading to a situation which looks pretty much the same to the client regardless if there is a network problem or just a buffering proxy present.

If you know you do not have a buffering proxy, you can use a custom ConnectionStateHandler to take the long polling connection state into account

[vaadin-bot]

Originally by mpilone

---

My last comment got eaten by the spam tracker. Let's try again.

Thanks for the information. It sounds like there are a couple of cases to handle.

1. Client connection fails (network or server down).
2. Client connection succeeds but buffering proxy closes the connection before any response.
3. Client connection succeeds and server pushes a response before anything times out.
4. Client connection succeeds but XHR request times out before buffering proxy pushes anything.

If I understand correctly, the issue is that the client can't easily distinguish between 1, 2, and 4 and therefore just avoids showing the connection lost message. Case 1 is where we want the message, 2 and 4 we probably don't.

Maybe an improvement would be to send an automatic heartbeat request (or full UIDL XHR) request to the server in these cases. It might mean an extra round trip for clients behind buffering proxies, but it would help the client distinguish between case 1 and 2 or 4 as soon as the push connection fails rather than waiting for the user to interact with the page or require a polling interval low enough to display a message in a reasonable time frame.

[vaadin-bot]

Originally by @TatuLund

---

Changed the type of the ticket to "enhancement".

[vaadin-bot]

Originally by proaccountapp

---

Removed prioritization date.

[stale[bot]]

A lot of tickets have been left hanging in the issue tracker through the years. Some of them are still relevant, some of them have been fixed a long time ago and some are no longer valid. To get a better look on what is important and still relevant, we are closing old tickets which have not been touched in a long time. No further work will be done on this ticket. If the ticket seems to be still actual, please verify the problem existence over latest framework version and then open a new ticket in vaadin/framework with all the suitable information.