The current connections count keeps increasing in my Elasticache Redis node

Question

I am using Jedis in a tomcat web app to connect to an Elascticache Redis node. The app is used by hundreds of users in day time. I am not sure of this is normal or not, but whenever I check the current connections count with cloudwatch metrics, I see the current connections increasing without falling down.

This is my Jedis pool configuration:

public static JedisPool getPool(){
        if(pool == null){
            JedisPoolConfig config = new JedisPoolConfig();
            config.setMinIdle(5);
            config.setMaxIdle(35);
            config.setMaxTotal(1500);
            config.setMaxWaitMillis(3000);
            config.setTestOnBorrow(true);
            config.setTestWhileIdle(true);
            pool = new JedisPool(config, PropertiesManager.getInstance().getRedisServer());
        }
        return pool;    
    }

and this is how I always use the pool connections to execute redis commands:

        Jedis jedis = JedisUtil.getPool().getResource();
        try{
            //Redis commands
            }
        catch(JedisException e){
            e.printStackTrace();
            throw e;
        }finally{
            if (jedis != null) JedisUtil.getPool().returnResource(jedis);
        }

With this configuration, the count is currently over 200. Am I missing something that is supposed to discard or kill unsused connections ? I set maxIdle to 35 and I expected that the count falls down to 35 when the traffic is very low but this never happened.

Answer 1

we had the same problem. After investigating a little bit more further we came across with this (from redis official documentation - http://redis.io/topics/clients) :

By default recent versions of Redis don't close the connection with the client if the client is idle for many seconds: the connection will remain open forever.

By default, aws provides a timeout value of 0. Therefore, any connection that has been initialised with your redis instance will be kept by redis even if the connection initialised by your client is down.

Create a new cache parameter policy in aws with a timeout different of 0 and then you should be good