Investigate compatibility with Spring Session

[heruan]

Spring Session provides a session management infrastructure and takes care of many features such as session expiration or serialization (including implementations for Redis and Hazelcast).

Leveraging Spring Session helpers and configuration would benefit the project reducing the low-level code to maintain and backend implementations, but it doesn't work out-of-the-box.

Flow creates its own VaadinSession during servlet initialization, while Spring uses a filter to replace the current HttpSession with its own specialized implementation. This two different approaches generate a conflict that triggers an infinite loop of UIDL requests.

Newer versions of Spring Session can be configured to store the sessions only when an attribute is set and to do this asynchronously, features that would both fit our use case, so it may be worth to investigate more thoroughly on the possibility to make Spring Session work with Vaadin.

This has been done in the past for older Vaadin versions: https://github.com/alejandro-du/vaadin-spring-session-redis so a similar approach might still be worth a try.

[heruan]

Some heads-up from my former investigation.

• Spring Session uses the SessionRepositoryFilter (in spring-session-core) as entry-point to replace the current session; the filter has an order of Integer.MIN_VALUE + 50 so there's still room to add a filter before this.
• Redis specific configuration happens with RedisHttpSessionConfiguration (in spring-session-data-redis) but it can be extended to provide e.g. a custom FlushMode or a custom SaveMode.

[mcollovati]

After some investigation, here is what actually happens with Vaadin + Spring Session + Redis Session Repository.

Firstly, some notes on VaadinSession:

• VaadinSession is created by Flow during request handling, not on servlet initialization, and it is stored into and retrieved from HttpSession. So, for Spring Session it is a simple attribute to serialize
• VaadinSession has a custom java serialization implementation (readObject(...) and writeObject(...)) to serialize the transient map of UIs. UIs are serialized by default only in production mode; in dev mode, the vaadin.devmode.sessionSerialization.enabled property must be set to true

In the out-of-the-box configuration of Redis HTTP Session, SessionRepositoryFilter is using RedisSessionRepository.
This implementation, for performance reasons, tries to reduce the amount of session attributes to be persisted on the backend; tracking method is configurable and can be: ON_SET_ATTRIBUTE (only persist attributes explicitly set with HttpSession.setAttribute()), ON_GET_ATTRIBUTE (persist all attributes that have been accessed during the request), ALWAYS (always persist all attributes).
The default value is ON_SET_ATTRIBUTE.

What happens is that

1. Browser sends a request for the Vaadin application, VaadinService creates a new VaadinSession and puts it into HttpSession (setAttribute). No UI is yet created at this time (IndexHtmlRequestHandler). VaadinSession is serialized and stored into Redis backend
2. UIDL init request is sent to the server, JavascriptBootstrapHandler create the UI and adds it to the VaadinSession. HttpSession.setAttribute() is not invoked, so the VaadinSession attribute is not tracked and consequently not updated into Redis backend
3. An UIDL request is sent to the server. VaadinSession is restored from Redis backend, but has no UIs, so UIDLRequestHandler detects an incoherent status and sends a session expired response
4. Flow client receives the session expired message and reloads the page
5. The above steps are repeated indefinitely, apart from VaadinSession creation and persistence, since setAttribute() is not called anymore.

Changing saveMode to ON_GET_ATTRIBUTE seems to solve the problem because VaadinService always tries to get VaadinSession from HttpSession. Thus, the attribute is tracked and persisted at every request.
This behavior may impact performance, but it is also true that most requests will update UI state, so serialization is required.

[heruan]

Thanks Marco for the thorough analysis! Did you also figure out if it is actually possible to do serialization asynchronously?

[mcollovati]

As a note, even if the Spring Session + Redis configuration works, we may still face problems with Java serialization.

For example, the demo project fails because of a Grid related serialization issue (a ticket already exist on Flow for this)

Caused by: org.springframework.core.serializer.support.SerializationFailedException: Failed to deserialize payload. Is the byte array a result of corresponding serialization for DefaultDeserializer?; nested exception is java.lang.ClassCastException: cannot assign instance of java.lang.invoke.SerializedLambda to field com.vaadin.flow.data.provider.AbstractDataProvider$DataListenerWrapper.registration of type com.vaadin.flow.shared.Registration in instance of com.vaadin.flow.data.provider.AbstractDataProvider$DataListenerWrapper
	at org.springframework.core.serializer.support.DeserializingConverter.convert(DeserializingConverter.java:78) ~[spring-core-5.3.22.jar:5.3.22]
	at org.springframework.core.serializer.support.DeserializingConverter.convert(DeserializingConverter.java:36) ~[spring-core-5.3.22.jar:5.3.22]
	at org.springframework.data.redis.serializer.JdkSerializationRedisSerializer.deserialize(JdkSerializationRedisSerializer.java:82) ~[spring-data-redis-2.7.2.jar:2.7.2]
	... 53 common frames omitted
Caused by: java.lang.ClassCastException: cannot assign instance of java.lang.invoke.SerializedLambda to field com.vaadin.flow.data.provider.AbstractDataProvider$DataListenerWrapper.registration of type com.vaadin.flow.shared.Registration in instance of com.vaadin.flow.data.provider.AbstractDataProvider$DataListenerWrapper

[mcollovati]

Did you also figure out if it is actually possible to do serialization asynchronously

Not yet. I'll take a look

[mcollovati]

Seems like serialization is done synchronously with Spring Session. Perhaps save operation can be performed async, but it requires a custom implementation.

[heruan]

Closing this as solved by replacing Spring Session with our own approach.