Objects missing in session in non-sticky environment about session-managers HOT 9 CLOSED

Hi Chris, I'd really appreciate your input on this. Other implementations I've looked at for storing Tomcat sessions in Redis write their own Manager which allows them to control the loading of the sessions from the store. eg. in jcoleman's implementation he says "Sessions are loaded as requested directly from Redis (but subsequent requests for the session during the same request context will return a ThreadLocal cache rather than hitting Redis multiple times.)".

If I can't guarantee that the session will be loaded from the Redis store with each request then things just don't work in a non-sticky environment, which is surely one of the drivers for storing the session in Redis (it was for me anyway). Thanks!

from session-managers.

Thinking about it some more I think a good plan would be for me to download the source and debug to see what's going on. I suspect that sessions from one of the Tomcat instances are clobbering the sessions of the other. Can you tell me a good place to put a breakpoint in the code to see when the session is being written to/read from redis. Is it in the SessionFlushValve invoke method?

from session-managers.

The problem seems to be that Tomcat is not always loading the session from the Redis store for each request. Instead it's getting the session from memory (sessions attribute in ManagerBase). How can I force Tomcat to load the session from the store every time? Without this things don't work in a non-sticky environment.

from session-managers.

Hi, @stuartjackson23!
As I understand, you're now using jcoleman/tomcat-redis-session-manager. If so, can you please share your experience of using it? Did it solve your issue? Have you encountered any other problems during use?

from session-managers.

We have done some initial testing with jcoleman's implementation but haven't moved forward with it yet to production. We haven't found any issues so far.

I was hoping that someone was going to tell me that I was doing something wrong with the pivotal implementation as I'd rather stick with it since it's more actively developed and it supports Tomcat 8 which we're currently on.

from session-managers.

@stuartjackson23 I've got some cycles to spend on this issue this. Are you still having problems as noted in your initial post>

from session-managers.

Hi Chris, Yes I couldn't get past these issues. It would be great if you could have a look at it.

from session-managers.

Hi all - I'm seeing this issue as well. We had been using the jcoleman/tomcat-redis-session-manager, but came across an edge case where it was breaking due to the use of the ThreadLocal storage. We have been testing with this implementation, but I'm now running into an issue very similar to the one described in this bug.

I'm happy to help if I can in tracing what's going on.

from session-managers.

Well, for what it's worth - it appears that the Tomcat PersistentManager is not intended to be used for what @stuartjackson23 and I are trying to use it for, namely storing all session data outside of Tomcat and loading it for every request. The tomcat-redis-session-manager provides its own Manager interface for this very reason.

I think what I'm going to have to do is go fix my edge case in that codebase rather than using this one. I'll post here if anybody wants the updated version.

from session-managers.