Jedis connection timeout problem resolution (JedisPool connection pool usage instance)

  • 2020-04-01 03:22:40
  • OfStack

Today I found Jedis =new Jedis(" localhost ",6379), the default connection mode of Jedis. Connection timeout always occurs. Later, I found that Jedis class package also has a method to set the maximum connection time.

1 - > To get the Jedis instance, you need to get it from JedisPool.
2 - > After using the Jedis instance, you need to return it to JedisPool;
3 - > If Jedis makes a mistake in use, you also need to return it to JedisPool;
The following code


JedisPoolConfig config = new JedisPoolConfig();

  config.setMaxActive(100);

  config.setMaxIdle(20);

  config.setMaxWait(1000l);
  JedisPool pool;
  pool = new JedisPool(config, "2xx.xx.xx.14", 6379);

  boolean borrowOrOprSuccess = true;
  try {
   jedis = pool.getResource();
   // do redis opt by instance
  } catch (JedisConnectionException e) {
   borrowOrOprSuccess = false;
   if (jedis != null)
    pool.returnBrokenResource(jedis);

  } finally {
   if (borrowOrOprSuccess)
    pool.returnResource(jedis);
  }
  jedis = pool.getResource();

JedisPool relies on the apache class package

The Commons - the pool - 1.5.6. Jar

1 - > Although a JedisConnectionException is thrown, there are actually two types of errors, one is pool.getreource (), and no jedis instance is available. The other class is jedis.set/get which also throws this Exception; In order to achieve the distinction, the instance is implemented according to whether it is null or not. If it is null, the instance is not initialized at all, so it is not necessary to return to the pool. If instance is not null, it turns out to be returned to the pool;
2 - > In the case of an instance error, the returnBrokenResource is also called to return to the pool. Otherwise, the buffer of the instance obtained through getResource may still have data.

The configuration parameters of JedisPool are largely dependent on the actual application requirements, hardware and software capabilities. Commons -pool has never been used before, so this time I spent an entire room looking at what these parameters mean... The configuration parameters of JedisPool are mostly assigned by their counterparts in JedisPoolConfig.

MaxActive: controls how many instances of jedis can be assigned to a pool, and gets them by pool.getresource (). If the value is -1, there is no limit; If the pool has been assigned maxActive instances of jedis, the pool state is exhausted, in JedisPoolConfig

MaxIdle: controls the maximum number of jedis instances whose state is idle in a pool.

WhenExhaustedAction: when finished the jedis instances in the pool are allocated, the pool to take action; There are three default WHEN_EXHAUSTED_FAIL (said no jedis instance, direct selling

NoSuchElementException), WHEN_EXHAUSTED_BLOCK (is blocked, or achieve maxWait thrown when JedisConnectionException), WHEN_EXHAUSTED_GROW (indicates a new jedis instance, also say, set maxActive useless);

MaxWait: represents the maximum waiting time when a jedis instance of borrow is taken. If the waiting time is exceeded, JedisConnectionException is thrown directly.

TestOnBorrow: whether to perform an alidate operation in advance when a jedis instance is borrowed; If true, the resulting jedis instances are available;

TestOnReturn: whether to validate in advance when returning to the pool;

TestWhileIdle: if true, there is an idle object evitor thread to scan the idle object. If validate fails, the object will be dropped from the pool. This item is only meaningful when timeBetweenEvictionRunsMillis is greater than 0;

TimeBetweenEvictionRunsMillis: it means the idle object evitor between two scans to sleep the number of milliseconds;

NumTestsPerEvictionRun: represents the number of objects that the idle object evitor scans the most at a time;

MinEvictableIdleTimeMillis: an object at least stay in the idle state of the shortest time, and then you can be idle object evitor scans and expelling; This item is only meaningful when timeBetweenEvictionRunsMillis is greater than 0;

SoftMinEvictableIdleTimeMillis: on the basis of minEvictableIdleTimeMillis, joined at least minIdle target has had in the pool. If it's -1, evicted won't evict anything based on idle time. If minEvictableIdleTimeMillis> 0, the set the meaningless, and is only meaningful when timeBetweenEvictionRunsMillis is greater than 0;

Lifo: borrowObject returns DEFAULT_LIFO (last in first out, the most frequently used cache-like queue), False for a FIFO queue.

The default Settings of some parameters of JedisPoolConfig are as follows:
TestWhileIdle = true
MinEvictableIdleTimeMills = 60000
TimeBetweenEvictionRunsMillis = 30000
NumTestsPerEvictionRun = 1


Related articles: