Verify demo project scaling on a kubernetes-scaling based prototype

[mcollovati]

Create a spike branch with an application scaling prototype base on Artur's work (https://github.com/Artur-/kubernetes-scaling) and compare pro/cons with the SpringSession approach (branch spikes/spring-session-workarounds).

[mcollovati]

I've pushed the branch issues/19-custom-session-handling that imports kubernetes-scaling prototype into Azure Kit. The project still has dependencies on spring session artifacts, but only to preserve existing configuration and transitive dependencies on redis and hazelcast. However, the Spring Session Filter is disabled in the demo and is replaced by the custom SessionTrackerFilter Actual implementation requires a patched Flow version 23.3.sess-SNAPSHOT, so also Vaadin version has been upgraded to 23.3-SNAPSHOT.

The demo works fine on local cluster with both Redis and Hazelcast as backend storage. Also, PUSH (XHR+websocket) is working correctly.

Here some opinions

• pros

  • Vaadin application works on in memory HttpSession provided by the container, so PUSH and closures works without any problem
  • Serialization is performed asynchronously
  • Optimistic/Pessimistic locking mechanism to prevent stale updates of the remote copy
  • Can be ported to non-Spring environments

• cons

  • Serialization is performed by our component and not delegated to the backend. We may lose customizability and potential performance improvements provided by Redis, Hazelcast, etc.
  • Spring Security integration needs to be implemented
  • Tracking is limited to UIDL requests, should be extended to other kinds of request (e.g. stream resources) or perhaps to every request (user may have custom code that changes HttpSession but not VaadinSession)
  • changes during PUSH handling (websocket) are not serialized until next HTTP request (a workaround is to serialize session after AtmospherePushConnection.send)
  • Session expiration should perhaps be handled on backend store
  • Does it handle correctly HttpServletRequest.changeSessionId? Do we need a HttpSessionIdListener?
  • An additional cookie is needed to track the remote session copy (minor drawback)
  • serialization locking needs changes in Flow (minor drawback)

Some additional notes:

• As with other solutions, (e.g. Spring Session), there's no out of the box way to re-initialize transient fields (i.e. injected services).
• I wonder if firing a SessionChangedEvent on VaadinSession.unlock() only when there are actual changes, would help in deciding whether or not to serialize the session.

[Artur-]

Serialization is performed by our component and not delegated to the backend. We may lose customizability and potential performance improvements provided by Redis, Hazelcast, etc.

I wonder if we could still delegate the serialization part to Spring Session?

Tracking is limited to UIDL requests, should be extended to other kinds of request (e.g. stream resources) or perhaps to every request (user may have custom code that changes HttpSession but not VaadinSession)

If the timestamps are stored in the session, maybe we can use that to see if we need to serialize it or not.

Session expiration should perhaps be handled on backend store

Expiration should delete the session from the backend store. It was not in the prototype

[Artur-]

This logic is probably invalid if you want to serialize the session, populate it again and keep using it on the same host https://github.com/vaadin/flow/blob/c802dbe7c096baf756bd079ce029bdb5b601da53/flow-server/src/main/java/com/vaadin/flow/server/VaadinSession.java#L185-L218

[Artur-]

There seems to be a VaadinService.PRESERVE_UNBOUND_SESSION_ATTRIBUTE flag to handle this case which basically skips all logic

[heruan]

Done in https://github.com/vaadin/azure-kit/pull/20