Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RedisIndexedSessionRepository: PRINCIPAL_NAME_INDEX_NAME index not cleaned up when applications use key namespace/prefix #3334

Open
bronio opened this issue Feb 5, 2025 · 0 comments
Labels
status: waiting-for-triage An issue we've not yet triaged type: bug A general bug

Comments

@bronio
Copy link

bronio commented Feb 5, 2025

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.

@bronio bronio added status: waiting-for-triage An issue we've not yet triaged type: bug A general bug labels Feb 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-triage An issue we've not yet triaged type: bug A general bug
Projects
None yet
Development

No branches or pull requests

1 participant