Spring boot, Spring session and Vaadin

I need help configuring my Vaadin application so it can be used in “clustered” environment where multiple nodes share the same session information. Configuring Spring Boot with Spring Session was almost trivial with the following documentation:
http://docs.spring.io/spring-session/docs/current/reference/html5/guides/boot.html
.

However, my Vaadin application refuse to work as soon as Spring sessions are involved and the following message appears in the debug console:

“Response didn’t contain a server id. Please verify that the server is up-to-date and that the response data has not been modified in transmission.”

Am I missing something here? I’m not sure if I need to make additionnal changes in order for this to work.

Thanks for you help.

Hi,

I’ve been playing a bit with Spring Session and Vaadin and run into the same issue. It seems that data in the session is sent to the Redis server before the
VaadinSession
instance has been fully configured which causes an old version of the instance to be persisted in Redis. Unfortunatelly, the fix would be easier to implement if the
RedisOperationsSessionRepository
class had some extension mechanisim regarding “deltas” and “caches”. The only workaround I have found so far is to use a
modified version of that class
.

I created a
demo application
showing what’s currently needed.

As an alternative, you could try GemFire which seems to work well with Vaadin.

Hi Alejandro,

Thank you very much for your help.

I’ve tried your proposed solution with my project. Using the modified
RedisOperationsSessionRepository
class seems the problem described above, however I now get an NullPointerException on the server side.

java.lang.NullPointerException: null at org.springframework.session.data.redis.RedisOperationsSessionRepository$RedisSession.saveDelta(RedisOperationsSessionRepository.java:788) at org.springframework.session.data.redis.RedisOperationsSessionRepository$RedisSession.access$0(RedisOperationsSessionRepository.java:781) at org.springframework.session.data.redis.RedisOperationsSessionRepository.save(RedisOperationsSessionRepository.java:401) at org.springframework.session.data.redis.RedisOperationsSessionRepository.save(RedisOperationsSessionRepository.java:1) at org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.commitSession(SessionRepositoryFilter.java:244) at org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.access$100(SessionRepositoryFilter.java:214) at org.springframework.session.web.http.SessionRepositoryFilter.doFilterInternal(SessionRepositoryFilter.java:167) at org.springframework.session.web.http.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:80) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:197) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192) The call to
VaadinService.getCurrent()
returns null the third time it gets called somehow. Maybe the Vaadin context is not present somehow on that third call. Any hints?

Hi,

I’ve literally just published an add-on with an alternative to this “hack”:


https://vaadin.com/directory#!addon/spring-session-redis

Let me know if it helps :slight_smile:

No it doesn’t help, even worst I’m back to square one. :frowning:

This is what my current configuration looks like:

        <dependency>
             <groupId>org.springframework.session</groupId>
             <artifactId>spring-session</artifactId>
        </dependency>
        <dependency>
             <groupId>org.springframework.boot</groupId>
             <artifactId>spring-boot-starter-redis</artifactId>
        </dependency>
        <dependency>
            <groupId>org.vaadin</groupId>
            <artifactId>spring-session-redis</artifactId>
            <version>1.0</version>
        </dependency>


@EnableRedisHttpSession
public class HttpSessionConfig {
}

@Configuration
@ServletComponentScan("org.vaadin.spring.session.redis")
public class ApplicationConfiguration {
  
}

What kind of error do you get?

Same as error before, on the client side:


“Response didn’t contain a server id. Please verify that the server is up-to-date and that the response data has not been modified in transmission.”

It’s almost like the new add-on as no effect. Maybe it’s a configuration issue?

Yes, maybe a configuration issue, try moving the @EnableRedisHttpSession annotation to the ApplicationConfiguration class.

Hi,
Serializing each and every component used in UI or VIEW is insane! I have few questions, please help me to get through, I’m stuck!

  1. Do I really need to serialize every component injected into UI or View ? is there any workaround ?
  2. Even when I serialize each piece, it’s complaining VaadinManagedSecurity not serialized!! What should I do ?

Lastly, we know serialization should be used judiciously, wrapping every component (including spring services) doesn’t introduce performance issue as tradeoff doing session externalization ?

Thank you.

Hi,

Yes, when the UI contains too many UI components, serializing the session might become a problem, mostly in distributed systems where replication occurs.

  1. You can use the
    transient
    keyword to avoid serializing fields you don’t need to serialize. Alternatively, you can get instances from an external helper class/service instead of letting a framework (Spring?) inject them in the class scope.
  2. I guess
    VaadinManagedSecurity
    comes from a third-party library. You should check with the author about it.

The more fields you need to serialize, the more computation time is required. This is important mostly when you want to replicate the session in a cluster.

Use sticky sessions disable session replication. All advices make things transient will cause that the client serialized session will be invalid after deserialization. you will got a plenty NPE.