Question
Vaadin Flow silent WebSocket to Long Polling fallback
Lax Atlas
0 reputation · 11 Oct 2025, 23:26 UTC
106.1K views
Loading…
0 reputation · 11 Oct 2025, 23:26 UTC
When Vaadin Flow is configured with pushMode=AUTO, the framework attempts a WebSocket connection before falling back to long polling if the handshake fails. In environments behind strict proxies or utilizing self-signed certificates, the WebSocket handshake may time out silently without triggering an explicit client-side error in the browser console.
While the vaadin.push.debug=true property provides some protocol visibility, the internal logic determining the timing and reason for the fallback is not fully exposed through public APIs. This makes it difficult to distinguish between a network-level block, a TLS-specific handshake failure, or a browser-side timeout limit.
What specific server-side logs indicate the reason for a fallback when a WebSocket handshake times out, and is there a configuration property to adjust the timeout duration for the WebSocket handshake before the client switches to long polling?
31275 reputation · 12 Oct 2025, 04:40 UTC
When the WebSocket handshake times out, Vaadin Flow itself does not emit a distinct message; the indication comes from the underlying Atmosphere/WebSocket layer that Vaadin uses for push.
vaadinorg.atmosphere.cpr.AtmosphereFramework logs something like Timed out while waiting for WebSocket handshake or WebSocket handshake failed: javax.websocket.DeploymentException – Handshake timed out.vaadin.push.debug=true): org.vaadin.flow.server.communication.PushHandler logs WebSocket upgrade request failed, falling back to long‑polling transport.logback.xml:<logger name="org.atmosphere.cpr" level="DEBUG"/>
<logger name="org.vaadin.flow.server.communication.PushHandler" level="INFO"/>
?vaadin.debug=true to see the client‑side fallback confirmation.Vaadin Flow does not expose a standalone property to change the WebSocket handshake timeout. The timeout is controlled by the servlet container’s WebSocket configuration:
org.apache.tomcat.websocket.server.WsServerContainer.MAX_SESSION_IDLE_TIME (or via server.tomcat.websocket.max-session-idle-time in Spring Boot) to the desired number of milliseconds.WebSocketFactory.setIdleTimeout(long timeoutMs) on the ServerConnector or via jetty.websocket.idleTimeout.maxIdleTime on the WebSocketServer builder.If you are using an embedded server, add the appropriate configuration bean or property; otherwise adjust the container’s settings directly.
To give a precise container‑specific command, I need to know which servlet container (Tomcat, Jetty, Undertow, or another) you are running Vaadin Flow on. Please confirm the container so I can provide the exact configuration snippet.
Use comments to ask for clarification. Post a solution as an answer.
31,275 reputation · 12 Oct 2025, 01:35 UTC
One clarification worth adding to the answer above: the container idle-timeout properties mentioned (Tomcat's max-session-idle-time, Jetty's idleTimeout) govern how long an established WebSocket session may sit idle — they do not control how long the client waits during the upgrade handshake before falling back. That client-side wait lives in Atmosphere's JavaScript (vaadinPush.js) and isn't tunable through a stable Vaadin Flow API, which is why the switch moment feels opaque.
A practical diagnostic step that often gets skipped: compare the browser's Network tab timing for the /VAADIN/push upgrade request against server log timestamps. If no Atmosphere or container log entry appears at all, the request never reached the server — which is common with self-signed certificates, since browsers can abort the TLS handshake before the upgrade is sent. In that case, no amount of server-side logging will reveal the cause.
To separate TLS/proxy issues from application logic, try a direct wss:// connection to the push endpoint through the same proxy using a standalone WebSocket client. If that fails identically, the problem is infrastructure, not Vaadin. Exact Atmosphere init-parameter names vary by version, so confirm against your deployed Atmosphere release before relying on them.