Vaadin Flow session memory keeps a low-traffic app on an oversized instance — is passivation viable?

Is Passivation Viable?

Yes, session passivation is a viable strategy to reduce the memory footprint of a low-traffic Vaadin Flow application. By moving idle session state to an external store (like Redis or JDBC via Spring Session), you can size your instance based on active concurrent users rather than the total number of sessions awaiting timeout.

Verifying Serializability

Because Vaadin Flow stores the entire UI component tree in the session, any non-serializable field in a View—such as an injected Spring service, an open InputStream, or a lambda capturing non-serializable state—will cause passivation to fail. To verify this without relying on runtime NotSerializableException errors, use these methods:

• Automated Serialization Tests: Create a unit test that manually serializes and deserializes your primary View classes using ObjectOutputStream and ObjectInputStream. This forces the JVM to traverse the object graph and throw an exception immediately if a field is not serializable.
• Static Analysis: Use a custom ArchUnit rule or a bytecode scanner to ensure all classes extending com.vaadin.flow.component.Component (or your base View class) implement java.io.Serializable and that their fields are either serializable or marked transient.

Measuring Heap per Session

To size a smaller instance, you must determine the average memory cost of a single user session. Since Vaadin's memory usage scales with the complexity of the UI tree, follow this approach:

1. Baseline: Start the app and capture a heap dump using jmap or VisualVM with zero users.
2. Simulated Load: Use a tool like JMeter or a JUnit @RepeatedTest to create a fixed number of sessions (e.g., 50 or 100) that navigate through the most complex views in your app.
3. Delta Calculation: Capture a second heap dump. Subtract the baseline from the loaded heap and divide by the number of sessions.
4. Safety Buffer: Add a 20–30% overhead to account for JVM fragmentation and temporary objects created during request processing.

Spring Session and Vaadin Interaction

Spring Session passivation does not override Vaadin's internal session management, but they must be aligned to avoid unexpected behavior:

• Session Lifetime: The effective session lifetime is governed by the Spring Session timeout. Vaadin's heartbeat mechanism helps keep the session alive while the browser tab is open, but once the heartbeat stops and the session is passivated, it will still be evicted from the external store once the Spring Session timeout is reached.
• Heartbeat Settings: Ensure your Vaadin heartbeat interval is shorter than your session timeout. If the heartbeat is too infrequent, the container may passivate the session while the user is still active, leading to a slight latency spike upon the next interaction as the state is deserialized.

Diagnostic Requirement: To refine this recommendation, please provide the average number of components per view. If views are exceptionally large (thousands of components), the CPU overhead of frequent serialization/deserialization may outweigh the memory savings of a smaller instance.