PRINCIPAL_NAME_INDEX_NAME some times cant clean up

[wash1983]

like this if not exists session, remove index when get it. is this ok?

        @Override
	public Map<String, RedisSession> findByIndexNameAndIndexValue(String indexName, String indexValue) {
		if (!PRINCIPAL_NAME_INDEX_NAME.equals(indexName)) {
			return Collections.emptyMap();
		}
		String principalKey = getPrincipalKey(indexValue);
		Set<Object> sessionIds = this.sessionRedisOperations.boundSetOps(principalKey).members();
		Map<String, RedisSession> sessions = new HashMap<>(sessionIds.size());
		for (Object id : sessionIds) {
			RedisSession session = findById((String) id);
			if (session != null) {
				sessions.put(session.getId(), session);
			}else{
                             this.sessionRedisOperations.boundSetOps(principalKey).remove(session.getId());
                       }
		}
		return sessions;
	}

[marcusdacoregio]

Hi, @wash1983. I did not understand what you are asking here, could you please re-elaborate the question?

[wash1983]

In the context of spring session date redis, there is a problem where the sessions are not being cleared when the application server crashes, leading to an accumulation of the index which causes delays when using sessionManagement to restrict the number of user login sessions. My question is, is it possible to add validation in theorg.springframework.session.data.redis.RedisIndexedSessionRepository.findByIndexNameAndIndexValue(String, String) method so that we can clean up the sessionId in PRINCIPAL_NAME_INDEX_NAME for the expired sessions? This way, even if the PRINCIPAL_NAME_INDEX_NAME is not cleaned up immediately when a session expires, it can still be cleaned up when accessed. add code }else{ this.sessionRedisOperations.boundSetOps(principalKey).remove(session.getId()); }

[marcusdacoregio]

I don't believe that we should apply that workaround because the problem relies on the mechanisms used to store the expirations and clean them. I'm working on a new Redis indexed implementation for WebFlux and there is a new mechanism that seems promising. We can then extend the current implementation to support specifying a different expiration policy.

[marcusdacoregio]

As a workaround, you can get all the keys matching the pattern spring:session:expirations:*, where the last part is the timestamp rounded up to the nearest minute. Then you can filter all keys with timestamp < last minute and check if the key inside the Set exists to trigger the expired event.

[marcusdacoregio]

Closing in favor of https://github.com/spring-projects/spring-session/issues/2906