今天遇到JedisPool的回收jedis连接一个大BUG

Jedis returnBrokenResource returnResource的标准写法:


Jedis 3.0 以后(含3.0)

finally{

if(jedis !=null) {

    jedis.close();

  }

}

If Jedis was borrowed from pool, it will be returned to pool with proper method since it already determines there was JedisConnectionException occurred. If Jedis wasn't borrowed from pool, it will be disconnected and closed.


Jedis 3.0 以前


publicStringget(String keyName)

{

Jedis redis =null;

try

    {

        redis = redisPool.getResource();

returnredis.get(keyName);

    }

catch(JedisConnectionException e)

    {

if(redis !=null)

        {

            redisPool.returnBrokenResource(redis);

redis =null;

        }

throwe;

    }

finally

    {

if(redis !=null)

        {

            redisPool.returnResource(redis);

        }

    }

}


You are supposed to use returnBrokenResource when the state of the object is unrecoverable. A Jedis object represents a connection to Redis. It becomes unusable when the physical connection is broken, or when the synchronization between the client and server is lost.

With Jedis, these errors are represented by the JedisConnectionException. So I would use returnBrokenResource for this exception, and not the other ones.

JedisDataException is more related to bad usage of the Jedis API, or to server-side Redis errors.

JedisException is for everything else (usually raised after a lower-level error, independant from Jedis).

猜你喜欢

转载自blog.csdn.net/weixin_34364135/article/details/88131236
今日推荐