Implement a retry for getConnection when the enableRedisKeyspaceNotificationsInitializer bean is created

[daromnik]

Hello.

I got a little problem. When raising services, sometimes an error appears:

org.springframework.beans.factory.BeanCreationException: 
Error creating bean with name 'enableRedisKeyspaceNotificationsInitializer' 
defined in class path resource [org/springframework/boot/autoconfigure/session/RedisSessionConfiguration$SpringBootRedisHttpSessionConfiguration.class]: 
Invocation of init method failed; 
nested exception is org.springframework.data.redis.RedisConnectionFailureException: Unable to connect to Redis; 
nested exception is io.lettuce.core.RedisConnectionException: Unable to connect to 111.11.111.222/<unresolved>:6379

And the service does not rise: ERROR SpringApplication reportFailure - Application run failed.
But the next time you start everything starts without errors.

Is it possible to somehow retry getConnection LettuceConnectionFactory ?
Create some kind of customizer or connect to some kind of event?
I wanted the service try to get a connection several times and only then fall.

[jxblum]

First off, this issue occurs inside Spring Boot (auto-configuration), as was apparent from the error message you shared:

Error creating bean with name 'enableRedisKeyspaceNotificationsInitializer' 
defined in class path resource [org/springframework/boot/autoconfigure/session/RedisSessionConfiguration$SpringBootRedisHttpSessionConfiguration.class]: 

Additionally, it appears you are using Spring Session Data Redis for HTTP Session management.

You should start with the Spring Boot project (Issues), move to the Spring Session project (Issues) if necessary, and ultimately, if the underlying, root cause is Spring Data Redis, then, and only then, file an Issue ticket here.

Having said this, are you certain the Redis server(s) or (possibly) cluster is up and running at 111.11.111.222/<unresolved>:6379, listening on port 6379?

What is the <unresolved> part of the network connection here?

If the Redis server(s)/cluster is available (service(s) is/are up and running in the cloud, if deployed in AWS, for instance), are you certain there is not a network issue, such as firewall, proxy, routing/nat problem, or some other type of network issue present?

Given you are using the Lettuce driver, you can always configure the (Socket) connection timeout along other connections settings using a Spring Boot LettuceClientConfigurationBuilderCustomizer (Javadoc) to "customize" the Spring Data Redis LettuceClientConfigurationBuilder (Javadoc) used to construct a LettuceClientConfiguration object (Javadoc) that is passed to the LettuceConnectionFactory (Javadoc) during construction, which is then used to create (and possibly "pool") LettuceRedisConnections (Javadoc) for Redis operations initiated by your Spring Boot application.

In Spring configuration, you would:

@SpringBootConfiguration
class MyRedisConfiguration {

    @Bean
    LettuceClientConfigurationBuilderCustomizer lettuceCustomizer() {

        return lettuceClientConfigurationBuilder -> {
            // customize the builder creating the LettuceClientConfiguration object 
            // passed to the LettuceConnectionFactory
        };
    }

You would use a Spring Boot LettuceClientConfigurationBuilderCustomizer to "customize" the Spring Data Redis LettuceClientConfiguration, Lettuce ClientOptions object (Javadoc) from here, to then further customize the Lettuce SocketOptions object (Javadoc) with the builder from here.

Of course, with Lettuce anyway, you are limited to simply configuring (adjusting) the connection timeout with the SocketOptions.Builder, which corresponds to Socket.connect(:SocketAddress, timeout) (Javadoc).

You may have more options if you choose a pooled (Lettuce/Redis) connection factory, such as Spring Data Redis LettucePoolingClientConfiguration, which is an extension of the LettuceClientConfiguration. This will give you more options to configure the "pooled" connections, which is managed by Apache Commons 2 GenericObjectPool and associated configuration. Object Pools are generally equipped with the ability to "retry" filling the "minimum" number of pooled objects (e.g. "connections") until the min is met.

Just tossing out ideas for you to consider. However, it is not really the "framework's" responsibility to keep retrying connections or filling a pool, etc... that is the "driver's" responsibility, especially since this can vary from environment to environment as well as from 1 topology (e.g. standalone) to another (e.g. clustered).