Differentiating between connectTimeout in SocketOptions and defaultTimeout in RedisClusterClient

[visheshruparelia]

Hi,
My application uses AWS Elasticache. I am trying to follow this guide to increase my service's resiliency. One of the points being suggested is regarding the socket timeout:

Ensure that the socket timeout of the client is set to at least one second (vs. the typical “none” default in several clients). Setting the timeout too low can lead to numerous timeouts when the server load is high. Setting it too high can result in your application taking a long time to detect connection issues.

The pseudo code on how I am creating connections is:

RedisClusterClient redisClusterClient = RedisClusterClient.create(clientResources, redisUrl);
            // Topology refresh and periodic refresh
            ClusterTopologyRefreshOptions topologyRefreshOptions = ClusterTopologyRefreshOptions.builder()
                .enablePeriodicRefresh(true)
                .enableAllAdaptiveRefreshTriggers()
                .build();

            // Update cluster topology periodically
            redisClient.setOptions(ClusterClientOptions.builder()
                .topologyRefreshOptions(topologyRefreshOptions)
                .build());

StatefulRedisClusterConnection connection = redisClusterClient.connect(new ByteArrayCodec());

I was going through the lettuce docs and saw there are two timeout options available for this:

• Use connectTimeout field in SocketOptions
• Use defaultTimeout field in RedisClusterClient

I would really appreciate if someone could help me understand the differences between the two and which one works better for my use case.

[mp911de]

That looks pretty much like a duplicate of #1867.

[visheshruparelia]

Hi @mp911de thank you for your reply.

I did go through #1867 before posting this. However, I am still confused as to which one to use.
I tried using both SocketOptions and deafultTimeout() one at a time and ran some tests.

Here is what I did:
Test Case 1

• Set connectTimeout in SocketOptions to 1s and updated the redisClient object using setOptions() method.
• Use Litmuschaos to add latency of >1s to the calls made to AWS Elasticache.
• Use Elasticache failover API to bring down one of the nodes in the redis cluster.

Test Case 2

• Set defaultTimeout in redisClient to 1s.
• Use Litmuschaos to add latency of >1s to the calls made to AWS Elasticache.
• Use Elasticache failover API to bring down one of the nodes in the redis cluster.

Observation (For both TCs):

• The lettuce logs indicated that it is not able to connect to the node which was brought down (This was expected as AWS was still in the process of replacing it).
• Once the redis node was up in AWS EC, Lettuce logs showed that it was successfully able to reconnect to that node (This was unexpected as I was already adding latency to the calls made to AWS EC).

Am I missing some config here?
Thanks