Session preservation limits for rolling upgrades with Vaadin stateful UI

Answer

With a stateful Vaadin UI, no-perceived-downtime rolling upgrade is only realistic with sticky session affinity plus node draining and no Vaadin framework version change. Cross-node session continuity is not practical for a standard Vaadin app, and an active push WebSocket will be dropped on drain. If a Vaadin version change is part of the migration, session state cannot be kept compatible and clients must be forced to reload.

Confirmed facts

• Vaadin stores the UI component tree and related state in the HTTP session on the server. UI instances are not serializable by default.
• Session replication across nodes requires identical classpath and identical Vaadin framework version. Any mismatch breaks deserialization.
• Rolling upgrades with sticky sessions and draining keep an existing session alive on its original node until that node is drained. Clients that are moved to a different node lose their server-side UI state.
• A Vaadin major version change invalidates serialized UI state and client-side resources. Sessions must be invalidated or rebuilt, typically by forcing a client refresh.
• Active push connections use WebSocket. When a node is drained the WebSocket is closed. The client will attempt to reconnect via the load balancer, but without the original session the UI will reset.

Likely explanation for your constraints

Sticky sessions with draining is the only low-risk pattern for a small Vaadin app. It avoids needing session replication and avoids trying to serialize UI objects. Cross-node continuity would require custom session serialization and a guarantee of identical framework code on all nodes, which Vaadin does not support out of the box.

Push reconnection is not handled automatically for continuity. Vaadin will reconnect the transport, but the UI instance is tied to the original session. Acceptable client behavior during drain is a brief transport interruption followed by a full UI reload, not silent state preservation.

Steps needed for this case

1. Confirm migration scope. If Vaadin version is unchanged, proceed with sticky + drain. If version changes, plan for session invalidation.
2. Enable sticky session affinity at the load balancer for JSESSIONID.
3. Implement node draining: stop accepting new sessions, wait for in-flight requests to finish, then allow existing sessions to idle out or expire before terminating the node.
4. Do not enable session replication unless all nodes run the exact same build and you have verified UI state serialization.
5. Set client expectations for push: brief disconnect on drain, automatic reconnect, possible UI reload.

One missing diagnostic detail that changes the recommendation: Is a Vaadin version change included in this migration? If yes, session compatibility cannot be preserved and you must force client reloads and accept state loss.