Dispose off not working for ClusterCommandExecutor

[vidushiguptaa]

Here in below code, clusterCommandExecutor is only destroyed if disposeClusterCommandExecutorOnClose is true
`public void close() throws DataAccessException {

	if (!isClosed() && disposeClusterCommandExecutorOnClose) {
		try {
			clusterCommandExecutor.destroy();
		} catch (Exception ex) {
			log.warn("Cannot properly close cluster command executor", ex);
		}
	}

	super.close();
}`

But when getting the clusterConnection from JedisConnectionFactory or LettuceConnectionFactory, clusterConnection is created with disposeClusterCommandExecutorOnClose = false which is causing the resource leak
`protected LettuceClusterConnection(@nullable StatefulRedisClusterConnection<byte[], byte[]> sharedConnection,
LettuceConnectionProvider connectionProvider, ClusterTopologyProvider clusterTopologyProvider,
ClusterCommandExecutor executor, Duration timeout) {

	super(sharedConnection, connectionProvider, timeout.toMillis(), 0);

	Assert.notNull(executor, "ClusterCommandExecutor must not be null.");

	this.topologyProvider = clusterTopologyProvider;
	this.clusterCommandExecutor = executor;
	this.disposeClusterCommandExecutorOnClose = false;
}`

[jxblum]

What you fail to realize is, the ClusterCommandExecutor is not created by the connection classes in the case where the Jedis or Lettuce RedisClusterConnection constructors are "passed" an instance of ClusterCommandExecutor from the Jedis or Lettuce RedisConnectionFactory.

The difference for Jedis is here and here vs. here and here.

The difference in Lettuce is again here and here vs. here and here.

This is true for all Jedis and Lettuce RedisClusterConnection constructors that accept a ClusterCommandExecutor as an argument.

Only when either the Jedis or Lettuce RedisClusterConnection class implicitly creates the ClusterCommandExecutor on the caller's behalf is the Jedis or Lettuce RedisClusterConnection appropriately responsible for the "lifecycle" of the ClusterCommandExecutor.

If the ClusterCommandExecutor is passed to the constructors as an external argument, then caller is responsible for the "lifecycle". This is because, potentially, the ClusterCommandExecutor could possibly be a "managed" bean declared and registered in the Spring container (ApplicationContext). After all, ClusterCommandExecutor is a DisposableBean (lifecycle bean) that will be properly destroyed by the Spring container if managed as a bean.

For both the Jedis and Lettuce RedisConnectionFactory implementations, each creates connections by passing in the ClusterCommandExecutor created by the factories (for Jedis, see here; for Lettuce, see here).

This puts the JedisConnectionFactory and LettuceConnectionFactory solely in charge of the lifecycle for the ClusterCommandExecutor instance.

And, both JedisConnectionFactory as well as LettuceConnectionFactory appropriately release resources, too!

That is apparent in the destroy() lifecycle method of the RedisConnectionFactory. For Jedis, see here. For Lettuce, see here.

Both JedisConnecionFactory and LettuceConnectionFactory are Spring container lifecycle beans.

In addition, as the documentation describes, both JedisConnectionFactory and LettuceConnectionFactory are created as "managed beans" in the Spring container.

Therefore, it is very unlikely that Spring Data Redis directly, or via Spring Boot, is creating a "resource leak".