You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
We are using RedisIndexedSessionRepository in multiple Spring Boot applications (over 100), all connected to a single Redis cluster. Each application defines a unique namespace (Redis key prefix) and has access only to keys within its own namespace.
However, since Redis publishes key-deleted and key-expired events on general channels (without a namespace prefix), session removal and expiration events are not routed to the specific application that owns the session. Instead, these events are randomly consumed by any application connected to the cluster.
As a result:
SessionDestroyedEvent and SessionExpiredEvent cannot be reliably used
The PRINCIPAL_NAME_INDEX_NAME key is not properly cleaned up, leading to continuous growth over time
Could you provide any recommendations for addressing this issue? Additionally, are there any planned improvements in future versions to mitigate this behavior?
Expected behavior
Session key-deleted and Session key-expired events should be routed to the application owning the session.
The text was updated successfully, but these errors were encountered:
Describe the bug
We are using RedisIndexedSessionRepository in multiple Spring Boot applications (over 100), all connected to a single Redis cluster. Each application defines a unique namespace (Redis key prefix) and has access only to keys within its own namespace.
However, since Redis publishes key-deleted and key-expired events on general channels (without a namespace prefix), session removal and expiration events are not routed to the specific application that owns the session. Instead, these events are randomly consumed by any application connected to the cluster.
As a result:
Could you provide any recommendations for addressing this issue? Additionally, are there any planned improvements in future versions to mitigate this behavior?
Expected behavior
Session key-deleted and Session key-expired events should be routed to the application owning the session.
The text was updated successfully, but these errors were encountered: