Why does Spring Session use spring:session:expirations?

[chrylis]

It's not obvious what the purpose of the Redis spring:session:expirations keys is. Are these there so that the server can proactively identify sessions and force them closed on the HTTP(ish) end? If so, what happens in a load-balanced situation where you have multiple servers reading and writing to the session store simultaneously? Are there race issues on either appending or the actual expiration-time processing?

[rwinch]

It's not obvious what the purpose of the Redis spring:session:expirations keys is. Are these there so that the server can proactively identify sessions and force them closed on the HTTP(ish) end?

Did you see the explanations in the Javadoc and reference? Does this explain things for you? If not, please reopen and ask a more specific question.

If so, what happens in a load-balanced situation where you have multiple servers reading and writing to the session store simultaneously? Are there race issues on either appending or the actual expiration-time processing?

Thanks for pointing this out. After a bit of thought I created #93 to address this.

[chrylis]

Yes, I read that section of the reference. It's unclear exactly what additional logic is supposed to be run that simply expiring the Redis key wouldn't do and who's responsible for the cron job. The reference talks about "cleanup in a deterministic fashion", but why isn't expiration sufficient?

[rwinch]

I think I understand the confusion here. I made some clarifications to the reference. They will be deployed shortly.

Can you take a look and see if it helps? See d96c8f2

If that still doesn't clarify things, please create a new github issue and we can try to sort out in the next release (for now we are getting ready for GA).

[chrylis]

That's a lot clearer. I still think there's at least one race involved in the active-expiration case (where multiple frontend servers are running and one extends the session lifetime near expiration), but the impact there seems minimal and fail-closed.

[rwinch]

Thanks for all your feedback! I think this will help ensure things are more clear for other users.

As explained in #93 I do see a race condition in which the session expiration may be off by the longest HTTP request used with the session. Is this what you are referring to? If not, please feel free to create an issue and we can discuss there.

[chrylis]

I think my race is related but distinct, but I've been up too long to trace it clearly right now. If I'm right, the impact will be almost negligible anyhow. I'll revisit and post another issue if I'm able to nail it down, but I'm pretty sure the proper resolution will just be a doc note.

[ankurpathak]

@rwinch But from where the task is comming which access the keys on expiration making sure that redis delete
expired keys in deterministic manner. Can you please elaborate on the task which access keys on expiration. And how spring:session:expirations is related to that task.

[vpavic]

@ankurpathak The RedisOperationsSessionRepository section of reference manual, as well as class javadoc on RedisOperationsSessionRepository, should provide all the required info - did you read those?

Also see RedisHttpSessionConfiguration#configureTasks:

spring-session/spring-session-data-redis/src/main/java/org/springframework/session/data/redis/config/annotation/web/http/RedisHttpSessionConfiguration.java

Lines 246 to 250 in 3e9f6a3

	@Override
	public void configureTasks(ScheduledTaskRegistrar taskRegistrar) {
	taskRegistrar.addCronTask(() -> sessionRepository().cleanupExpiredSessions(),
	this.cleanupCron);
	}

[ankurpathak]

The points I got after reading are:

1. We create a cron task in RedisHttpSessionConfiguration that access expired keys once they expire using time stamps suffixes in spring:session:expirations * keys.
2. One we access them, since those keys have expired ttl redis delete them automatically.
   Am I correct? If not please correct me with your additions.