Closed salvorapisarda closed 1 year ago
This seems to be a Spring Session issue and not a Spring Data one. Please open an issue with them.
Spring Session supports "clustered" (HTTP, WebSocket
and (Reactive) WebSessions
) Sessions and uses the Session ID as the "key" of the Session when managing (storing and accessing) Sessions, even in a clustered environment.
Without an example reproducing the problem, or more information on your specific Spring Boot/Spring Session application configuration and setup, a Stack Trace, or something, it is very difficult to determine the exact reason for this error.
A quick Google search reveals a bit of information on why this error occurs (for example). If you are using Amazon AWS's ElastiCache, then you can find a bit of information here as well.
Having developed a Spring Session module (Spring Session for Apace Geode/VMware GemFire), I know there are certain circumstances where the Session ID can be changed (Expiration, Invalidation, ??). I don't remember all the specific details as it has been awhile. Maybe in Redis's case, Spring Session is trying to access the old and new (logically same) Sessions by ID in a single command, but each Session ID (key) maps to a different node/hash slot??
Under-the-hood, Spring Session Data Redis uses Spring Data Redis, so you should also review the appropriate documentation on (clustered) Redis connections and setup, starting here, and then, specifically and especially, here.
NOTE: It is quite possible you have not configured the
RedisConnectionFactory
correctly for your clustered environment.
All and all, I am simply theorizing here, so as @schauder mentioned above, I would start with the Spring Session project/team and work backwards, if necessary.
Hi
By using spring-session-data-redis and spring-boot-starter-data-redis in our web application, we are getting a "RedisCommandExecutionException: CROSSSLOT Keys in request don't hash to the same slot". This does not happen locally because the node is single.