GeminiDB Redis API Connection Test and Client Reconnection Retry Suggestions

The client and GeminiDB instance may be disconnected if packets are lost, jitter occurs, node specifications are changed, or a version is upgraded. To ensure successful operations, the client must have an automated reconnection mechanism. You are advised to use mainstream Redis clients, such as Jedis, to test connections before obtaining them or periodically check the status of idle connections to prevent operation timeout or failures caused by connection issues. In this way, system connectivity and reliability can be effectively improved.

• Set testonBorrow to check validity when obtaining connections.

  JedisPoolConfig poolConfig = new JedisPoolConfig();
  //Sets the validity check item when obtaining connections from the connection pool.
  poolConfig.setTestOnBorrow(true);
  //Other configurations
   
  //Uses the configurations when creating a connection pool.
  JedisPool jedisPool = new JedisPool(poolConfig, "localhost", 6379);

When testOnBorrow is set to true, the system checks connection validity by executing a ping command each time a connection is obtained from the connection pool. The system will discard an invalid connection and attempt to obtain another available connection. This configuration ensures that each obtained connection is valid but consumes more resources each time ping is executed. During traffic spikes, you can enable idle connection test (for example, setting testWhileIdle to true) to check connection validity before connections are used. This prevents extra resource consumption each time a connection is obtained, improving the overall performance.

• An idle connection test is performed by an asynchronous thread to check connection validity. Compared with testonBorrow, this option consumes fewer resources.

JedisPoolConfig poolConfig = new JedisPoolConfig();
poolConfig.setTestWhileIdle(true);
//Interval for testing idle connections. The value ranges from 30s to 60s.
poolConfig.setTimeBetweenEvictionRunsMillis(30000);
//Number of connections checked each time. A negative value is recommended, indicating that all idle connections are checked.
poolConfig.setNumTestsPerEvictionRun(-1);
//Minimum idle period of a connection. The test starts when the idle period exceeds this value.
poolConfig.setMinEvictableIdleTimeMillis(60000); //60s
JedisPool jedisPool = new JedisPool(poolConfig, "localhost", 6379);

If a Redis command fails to be executed, for example, due to timeout caused by network jitter, you can retry the command, such as SET key value, which is idempotent, to avoid the impact of temporary network problems. Retrying non-idempotent operations, such as LPUSH and LPOP may cause data to be inserted or deleted multiple times, leading to service logic errors. To ensure successful operations, you need to analyze whether a retry policy is suitable in specific scenarios and properly set the retry times and interval.

public <T> T executeWithRetry(RedisCommand<T> command, int maxAttempts) {
    JedisException lastException = null;
    
    for (int attempt = 1; attempt <= maxAttempts; attempt++) {
        try (Jedis jedis = jedisPool.getResource()) {
            return command.execute(jedis);
        } catch (JedisConnectionException e) {
            lastException = e;
            log.warn("Redis connection failed (attempt {}/{}): {}", 
                attempt, maxAttempts, e.getMessage());
           
                //Uses the sleep method or exponential backoff to retry a command after a period.
               Thread.sleep(waitTime);
        }
    }
    throw new RedisOperationException("Max retry attempts reached", lastException);
}