support for spring-session

[Firestorm87]

I would like to deploy my vaadin-flow application in an kubernetes cluster with stateless vaadin pods.
The http session should be stored in a redis-cluster via spring-session-data-redis.

If i add spring-session jdbc or redis to my vaadin-spring-boot-application the application is very slow and does a full page reload after a few seconds. Everything else looks like it is working normally.

There are no warnings or exception in frontend or backend.

How to reproduce:
add
spring-session-core
spring-session-data-redis

to pom of spring-boot-vaadin-app (e.g. bakery-app).

add

spring.session.store-type=redis
spring.redis.host=localhost
spring.redis.port=6379`

to application.properties

[Artur-]

The problems with Redis has previously been discussed in vaadin/framework#9189

[Firestorm87]

ok. it means spring session, or replicated sessions at all are generally not supported?

[Zacherl]

I have another issue with Spring, Vaadin and shared sessions with Redis.
When enabling shared sessions, it results in an exception:
java.io.NotSerializableException: com.vaadin.flow.spring.scopes.BeanStore

Any hint why this happens?

#9189 doesn't seem to cover this issue.

[miclefebvre]

Can someone confirm if it's supported to have a replicated session in Kubernetes ?

I found this blog post: https://vaadin.com/blog/microservices-high-availability
and this thread: https://vaadin.com/forum/thread/17277282/17277283 showing errors with session.

[Legioth]

Any form of session replication is very difficult to support with Vaadin's server-side architecture because of the way it's based on having a consistent server-side representation of what is currently shown in the user's browser. This architecture is a trade-off between developer convenience and some other qualities.

A more appropriate solution for most situations is to use sticky sessions in the load balancer. See https://vaadin.com/blog/microservices-high-availability and https://vaadin.com/blog/session-replication-in-the-world-of-vaadin for more information.

Since the main purpose of Spring Session is to enable session replication, this also means that it's very unlikely that we will add any support for it.

On the other hand, we are also investigating alternative ways of building applications without sacrificing end-to-end type safety and convenient access to backend services. You can read more about that initiative at https://vaadin.com/labs/vaadin-connect.

[sriharrsha]

Any update on vaadin-connect

[Legioth]

Any update on vaadin-connect

What was known as Connect on year ago has been a part of Vaadin since version 15. It's nowadays know as Vaadin Fusion.

Fusion uses the HTTP session only for keeping track of authentication and a CSRF token. This most likely very compatible with any typical session replication approach, but I haven't heard from anyone who would have tested it out in practice.

[sriharrsha]

So do you mean we can never achieve spring session support in Vaadin Flow project? If that's true is there any way to convert flow into fusion automatically?

Please fix this issue for Java World of Vaadin

[Legioth]

An architecture like Flow has benefits for e.g. security, developer productivity, and the convenience of doing everything in server-side Java. One of the sacrifices needed to get those benefits is that the HTTP session size is typically between 100 kb and 10 mb, which in turn makes session replication very impractical.

This is unfortunately a fundamental architectural tradeoff without any fix in sight.

[sriharrsha]

Is there any tutorial for sticky sessions instead of session replication on Vaadin Spring Boot for Google AppEngine. I added the session_affinity flag to true but it didn't work. The Vaadin App restarts continuously in an infinite loop due to automatic scaling.

[Legioth]

The way Google App Engine deals with sessions isn't a good fit with Vaadin if you want to scale beyond one instance. If you want to stick to Google's cloud offerings with a more complex deployment, then I'd recommend the Google Kubernetes Engine option described in https://vaadin.com/learn/tutorials/cloud-deployment/google.

Another alternative if you want to stick to the simplicity similar to GAE is to consider Heroku as an alternative. That approach is described in https://vaadin.com/learn/tutorials/cloud-deployment/heroku.

[Paulukr]

An architecture like Flow has benefits for e.g. security, developer productivity, and the convenience of doing everything in server-side Java. One of the sacrifices needed to get those benefits is that the HTTP session size is typically between 100 kb and 10 mb, which in turn makes session replication very impractical.

This is unfortunately a fundamental architectural tradeoff without any fix in sight.

Why impractical? 10mb isn't much for internal network and in-memory database.

[Legioth]

The main reason for using session replication is to enable working at a larger scale than what a single server can support. At such scales, 10 mb per request might lead to other bottlenecks.

That amount of data might or might not be a blocker depending on other circumstances, but it's surely 10000 times more impractical than the typical ~1 kb size that you'd get if the session only contains authentication information and not much more than that.

I can also mention the new-ish Hazelcast tutorial that shows a relatively practical approach to session replication even though it's still also based on first having a load balancer with sticky sessions and then accepting the small risk of corruption because of the lack of distributed locking in cases when a session needs to move between nodes.