JedisCluster.pipelined can optionally pass ExecutorService

[xiandafu]

JedisCluster.pipelined can optionally pass ExecutorService, like this

public ClusterPipeline pipelined(){
    
}
//new method
public  ClusterPipeline pipelined(ExecutorService  executorService){

}

In addition, in some cases, no additional Thread pool is required to perform the pipeline operation. This is because cloud vendor use the Redis proxy server in front of the Redis cluster to mask the cluster mode of Redis. JedisCluster only contains one HostAndPort. In this case, it is recommended not to use the Thread pool to execute the pipeline

public final void sync(){
if(syncing){
   return;
}
syncing=true;
if(pipelinedResponses.size()==1){
   pipelineRun()
}else{
   pipelineRunWithExecutorService()
}
…..
}

I think it's important that if there is a JedisConnectionException, MultiNodePipelineBase should contain exception information, and the caller should decide whether to retry based on this exception

public abstract class MultiNodePipelineBase   extends  PipelineBase{
	private Exception execption = …..
	
	
	public boolean isSuccess(){return exception!=null}
        public Exeception getExeception(){return exeception}
}

Finally, can we retry based on JedisConnectionException? such as

ClusterPipelinepipeline=cluster.pipelined()

pipeline.withRetry(5).sync()

If(pipeline.isSuccess()){
	获取结果
}

Thanks!!!

[yangbodong22011]

In addition, in some cases, no additional Thread pool is required to perform the pipeline operation. This is because cloud vendor use the Redis proxy server in front of the Redis cluster to mask the cluster mode of Redis. JedisCluster only contains one HostAndPort. In this case, it is recommended not to use the Thread pool to execute the pipeline

In this case, it is more reasonable for you to use the client (JedisPool) in Standalone mode.

I think it's important that if there is a JedisConnectionException, MultiNodePipelineBase should contain exception information, and the caller should decide whether to retry based on this exception

I agree with adding an isSuccess() function to indicate that no exceptions occurred. But retry is a troublesome thing, depending on whether the command itself is idempotent. And it is even more difficult when only part of the pipeline is successful.

[xiandafu]

thanks @yangbodong22011

In this case, it is more reasonable for you to use the client (JedisPool) in Standalone mode.

Yes, my application needs to be deployed in both Redis cluster environment and Redis Standalone environment . JedisCluster is more suitable for me : one code, deployed in multiple environments

And it is even more difficult when only part of the pipeline is successful.

yes, The method withRetry() is optional and is typically used for query operations. The caller needs to ensure that

[yangbodong22011]

Yes, my application needs to be deployed in both Redis cluster environment and Redis Standalone environment . JedisCluster is more suitable for me : one code, deployed in multiple environments

ok, but even if there is only one node, the execution of ClusterPipeline in the thread pool does not bring much overhead.

The current major overhead is thread creation and destruction each time, but our ongoing PR #3333 is fixing this