Adapt to Spring Session Data Redis switching to an unindexed repository by default

[wilkinsona]

See spring-projects/spring-session#1711 for background.

Spring Session's Redis module has switched to a simpler default repository implementation. This broke Boot's build as the simpler repository does not require a cleanup cron. 4a401bf has adapted to the breaking change but means that Boot's still using an indexed repository by default.

We should probably align our default with Spring Session's and use the simpler, more performant repository by default. To do so, we'll need to do something with the spring.session.redis.cleanup-cron as it only applies to the indexed repository. We may also want to provide a configuration property to control the type of repository that's used, making it easy for users to switch back to the indexed repository if they wish to do so.

/cc @eleftherias @vpavic

[bclozel]

This change also broke a smoke test - the session actuator endpoint relies on the indexed variant of the repository. The new default doesn't allow that and the session endpoint is not auto-configured.

This test has been ignored with 21eab01, until a decision is made here.

[philwebb]

We're not going to add a property to switch the implementations. If users want the indexed version then they'll need to configure it themselves.

[bclozel]

@vpavic with SessionRepository being the new default, right now the SessionsEndpoint completely backs off as it's relying on FindByIndexNameSessionRepository for its features.

SessionsEndpoint ships three operations currently:

spring-boot/spring-boot-project/spring-boot-actuator/src/main/java/org/springframework/boot/actuate/session/SessionsEndpoint.java

Lines 51 to 69 in 7f8e2d8

	@ReadOperation
	public SessionsReport sessionsForUsername(String username) {
	Map<String, ? extends Session> sessions = this.sessionRepository.findByPrincipalName(username);
	return new SessionsReport(sessions);
	}
	@ReadOperation
	public SessionDescriptor getSession(@Selector String sessionId) {
	Session session = this.sessionRepository.findById(sessionId);
	if (session == null) {
	return null;
	}
	return new SessionDescriptor(session);
	}
	@DeleteOperation
	public void deleteSession(@Selector String sessionId) {
	this.sessionRepository.deleteById(sessionId);
	}

We could provide a simple Endpoint variant with getSession and deleteSession, but we're wondering if removing the ability to list sessions for a username doesn't break the main use case for this. What do you think?

[eleftherias]

Adding that users may opt in to using a RedisIndexedSessionRepository by specifying @EnableRedisHttpSession(enableIndexingAndEvents = true).

I don't have background on SessionsEndpoint, but how does it work with other session stores that don't extend FindByIndexNameSessionRepository? I imagine that the new default implementation should work similar to the other stores, if they support such a feature.

[wilkinsona]

I've reinstated the smoke test in 061d86e. The app under test was using @EnableRedisHttpSession which was overriding Spring Boot's current opinion that the indexed repository should be used by default.

[wilkinsona]

Was anything decided about how to handle spring.session.redis.cleanup-cron which is specific to the indexed repository?