Jedis: Support of automated background topology refresh in cluster mode

[agarwalbharat]

Issue

Currently, when using JedisConnectionFactory from spring-data-redis, there is no support for configuring an automatic, periodic topology refresh for the Jedis client.

This functionality was initially added only for Lettuce. At that time, Jedis did not provide a feature and interface to enable background, periodic topology refresh.
Issue: spring-projects/spring-boot#15630

Jedis has added support for automated background topology refresh, allowing users to configure a period at which Jedis refreshes the cluster node topology.

This was done from jedis v5.1.0:
Implementation details in pull request: redis/jedis#3596

Fix

Added support for configuring the topology refresh period duration in the JedisClientConfiguration builder.
By default, this value is set to null.

• When no value is set for topologyRefreshPeriod in the configuration, null is passed to the Jedis constructor (the default Jedis behavior). In this case, Jedis does not create or perform automatic background topology refresh.
• When a Duration value is provided, it is passed to the Jedis constructor, and Jedis starts performing periodic topology refresh in the background.

Example Code: Enabling Automated Topology Refresh with a Configured Period

    JedisClientConfiguration clientConfig = JedisClientConfiguration.builder()
            .connectTimeout(Duration.ofMillis(connectTimeout))
            .topologyRefreshPeriod(Duration.ofSeconds(topologyRefreshInterval)) // setting period to refresh topology
            .readTimeout(Duration.ofMillis(readTimeout))
            .usePooling()
            .poolConfig(poolConfig)
            .build();
    RedisClusterConfiguration redisClusterConfig = new RedisClusterConfiguration(redisNodes);
    JedisConnectionFactory connectionFactory = new JedisConnectionFactory(redisClusterConfig, clientConfig);

Example Code: Disabling Automated Topology Refresh (Default/Existing Behavior)

    JedisClientConfiguration clientConfig = JedisClientConfiguration.builder()
            .connectTimeout(Duration.ofMillis(connectTimeout))
            .readTimeout(Duration.ofMillis(readTimeout))
            .usePooling()
            .poolConfig(poolConfig)
            .build();
    RedisClusterConfiguration redisClusterConfig = new RedisClusterConfiguration(redisNodes);
    JedisConnectionFactory connectionFactory = new JedisConnectionFactory(redisClusterConfig, clientConfig);

---

• You have read the Spring Data contribution guidelines.
• You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.
• You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

[mp911de]

JedisCluster is deprecated as of version 7.2. I wonder whether it would rather make sense to accept customizers for ClusterClientBuilder/SentinelClientBuilder/StandaloneClientBuilder so that we don't depend on individual configuration properties that we only utility for passing on.

[agarwalbharat]

That makes sense, @mp911de

While we might not be using this property directly right now, we do maintain a topology outside of Jedis as well. That topology currently has a hard-coded cacheTimeout of 100 ms, so I was wondering whether it would make sense to reuse this value there too in case, so that Jedis and this topology provider remain in sync with time too.

Given that JedisCluster is deprecated as a constructor, I could look into migrating this to the appropriate builder instead, if that aligns with the preferred direction.