Description
Expected Behavior
We should be cleaning up principle index keys in the method onMessage in RedisIndexedSessionRepository.java even if redis key is not found. It is due to if the MessageListener is not able to process the event within 5mins. After 5mins the sessions key will get expired and if the event get processed we return back from the method and the cleanup of principle index key doesn't happen. As a result the principal index key size will keep growing for these cases
Current Behavior
Currently we are not cleaning principal index keys if the session is not found in redis
Context
#3396
This issue is related to above. My observation in the above so far seems to be related to thread throttling. However if a I get sudden surge of session expired events (like during peak hours) as onMessage can't handle all those events within 5mins unless the CPU instance is really big large number of principal index keys aren't cleaned up. As a result the key size keeps getting huge leading to increase in redis memory
How has this issue affected you?
Increase in redis memory leading to increasing in cost as well
What are you trying to accomplish?
To cleanup stale session in principal index key
What other alternatives have you considered?
Running a async job myself to all session expired events
Are you aware of any workarounds?
None at the moment
Can someone please check this, I think this issue should be applicable for others as well who deal with huge number of sessions. I would like to work on it this is valid
The solution at the top of my mind I have right now is to move cleanUpPrincipalIndex above where we fetching session from redis