spring.data.redis.timeout doesn't seems to work with ReactiveStringRedisTemplate after upgrade to Spring Boot 3.1

[YeGaung]

Bug Report

We are using ReactiveStringRedisTemplate to execute Lua script for hset and expire operations.
The timeout is set as 5s by setting spring.data.redis.timeout environment so that the command timeout exception to be thrown if Redis server takes more than 5s to execute the given Lua script.

Current Behaviour

The call to execute method of ReactiveStringRedisTemplate seems to be hang forever when the Redis server is not returning the result instead of throwing exception upon the configured timeout.

Expected Behaviour

The timeout exception should be thrown if the Redis server is not returning within the configured timeout.

Supporting Information

The Expected Behaviour can be achievable by using StringRedisTemplate to execute the Lua script.

[jhengy]

To follow up, it seems that the issue has something to do with how LettuceConnectionConfiguration applies springboot application property "spring.data.redis.timeout". When the timeout is configured programatically via LettuceClientConfigurationBuilderCustomizer, timeout is then is applied correctly (client successfully throw RedisCommandTimeoutException when response is not returned within the configured timeout)

    public LettuceClientConfigurationBuilderCustomizer commandTimeoutBuilderCustomizer(
        @Value("${spring.data.redis.timeout}") Duration timeout
    ) {
        log.info("Redis command timeout configured");
        return builder -> builder.commandTimeout(timeout);
    }

[jxblum]

Have you tried inspecting the configuration of the command timeout at runtime when using the Spring Boot spring.data.redis.timeout property?

You can do this by acquiring a reference to the LettuceConnectionFactory instance (bean in the Spring container) and doing the following:

Duration commandTimeout = lettuceConnectionFactory.getClientConfiguration()
    .getCommandTimeout();

NOTE: LettuceConnectionFactory implements ReactiveRedisConnectionFactory.

NOTE: ReactiveStringRedisTemplate simply takes a ReactiveRedisConnectionFactory (which again, the LettuceConnectionFactory IS), and uses it to acquire connections having the appropriate configuration when executing all Redis commands.

If this problem occurs after upgrading to Spring Boot 3.1.x (from what?), then it would seem that the problem is with Spring Boot. Although, I rather think you have a problem in your application configuration, environment, or setup, somehow.

In any case, upon reviewing the Spring Boot auto-configuration for (Spring Data) Redis (from here, and specifically this), we see the declaration of the RedisConnectionFactory bean (i.e. LettuceConnectionFactory; here).

Subsequently, the LettuceClientConfiguration is built from Spring Boot configuration (such as declared application properties). See here in particular.

As you can see, the command timeout is applied to the client configuration that is used when constructing the connection factory.

The "properties" come from the RedisProperties (here to here then here) that Spring Boot creates from properties (e.g. spring.data.redis.* properties) declared in application.properties, or similar source.

At last, any user-defined customizers are applied to the LettuceClientConfiguration.

Of course, none of Spring Boot's auto-configuration is going to have any effect if you explicitly overrode and declared a LettuceConnectionFactory bean in your application configuration (hence this).

However, given that you declared a user-defined, Spring Boot LettuceClientConfigurationBuilderCustomizer (and it works), it would seem you haven't overridden the RedisConnectionFactory bean, so...

To verify, I confirmed the proper behavior of both Spring Data Redis and Spring Boot by writing a simple test class that uses Spring Boot 3.1.3 with Spring Data Redis 3.1.3. Indeed, everything works as expected.

Of course, I did not go on to test the (Reactive)StringRedisTemplate, specifically. However, that is only because whatever (command timeout) configuration used by the imperative or reactive templates has already been determined by the configuration specified in the connection factory passed to the template.

[jxblum]

If you can provide a small, simple example that reproduces your problem reliably in a Gist, I'd be happy to take a closer look.

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.