zoukankan      html  css  js  c++  java
  • redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool

    超时

    Exception in thread "main" redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out
        at redis.clients.jedis.Protocol.process(Protocol.java:79)
        at redis.clients.jedis.Protocol.read(Protocol.java:131)
        at redis.clients.jedis.Connection.getBinaryMultiBulkReply(Connection.java:199)
        at redis.clients.jedis.Jedis.hgetAll(Jedis.java:851)

    If what you want to do is set Jedis connection timeout, you should do it using the special constructor made for that:

        public Jedis(final String host, final int port, final int timeout)
    

    What you are doing is setting the timeout on redis settings from jedis.
    Doing CONFIG SET timeout 60, means that redis will close idle client connections after 60 seconds.
    That's why you get the exception in Jedis.

    The timeout parameter of the constructor is in milliseconds because this value is affected internally to java.net.Socket#connect(java.net.SocketAddress, int) and java.net.Socket#setSoTimeout(int) methods. So this this value is connection and a socket read timeout. 

    This is a bit of an extension to xetorthio's answer, but here is similar approach for use with a JedisPool. (Caveat: this is based on my understanding from looking at the Jedis version 2.6.2 code directly and has not been tested in a live use case.)

        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
        jedisPoolConfig.setMaxWaitMillis(writeTimeout);
        JedisPool pool = JedisPool(jedisPoolConfig, redisHost, port, readTimeout);

    The writeTimeout is max time for a Jedis resource from the pool to wait for a write operation.

    The readTimeout specified for the pool constructor is the wait time for a socket read, see java.net.Socket.setSoTimeout for more specific details.

    Few things to consider:

    1. For both Jedis and JedisPool classes, timeout is in miliseconds. Default timeout, at least in 2.5.1, as I see, is 2000 (milisec): int redis.clients.jedis.Protocol.DEFAULT_TIMEOUT = 2000 [0x7d0]

    2. As per this documentation, recent version of Redis does not close connection, even if the client is idle. I have not verified this yet, and I will try to update the post when I do.

    http://stackoverflow.com/questions/14993644/configure-jedis-timeout

    https://github.com/xetorthio/jedis/issues/1190

    1. redis server, no changes during all test
      redis_version:2.6.9

    2. We've been upgrading jedis client from 2.0.0 to 2.7.3, with the same configuration parameters, 
      we saw a lot more exceptions like below

    Exception in thread "Thread-4" redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
        at redis.clients.util.Pool.getResource(Pool.java:50)
        at redis.clients.jedis.JedisPool.getResource(JedisPool.java:99)
        at com.yaojuncn.jedis.JedisPerfTest$.onecall(JedisPerfTest.scala:94)
        at com.yaojuncn.jedis.JedisPerfTest$$anonfun$runthreadtest$1$$anon$1$$anonfun$run$1.apply$mcVI$sp(JedisPerfTest.scala:69)
        at scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:141)
        at com.yaojuncn.jedis.JedisPerfTest$$anonfun$runthreadtest$1$$anon$1.run(JedisPerfTest.scala:68)
        at java.lang.Thread.run(Thread.java:745)
    Caused by: java.util.NoSuchElementException: Timeout waiting for idle object
        at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:449)
        at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)
        at redis.clients.util.Pool.getResource(Pool.java:48)
        ... 6 more
    
    1. after some hard time, finally reached the test code of below with 2.7.3 version,https://github.com/yaojuncn/jedis273concurrentperftest/blob/master/src/main/scala/com/yaojuncn/jedis/JedisPerfTest.scala

    we saw a lot of pool.getResource invocations longer than 20ms.... (if we uncomment out line 37 of above source file we will see a lot of exceptions)
    https://github.com/yaojuncn/jedis273concurrentperftest/blob/master/jedis2.7.3.sampleoutput.txt

    with 2.0.0 version
    https://github.com/yaojuncn/jedis200concurrentperftest/blob/master/src/main/scala/com/yaojuncn/jedis/JedisPerfTest.scala
    the output is pretty clean
    https://github.com/yaojuncn/jedis200concurrentperftest/blob/master/jedis2.0.0.sampleoutput.txt

    1. I guess this is related to the apache-common pool version that jedis is using and I do saw the FAQhttps://github.com/xetorthio/jedis/wiki/FAQ and issues listed here like
      #844

    but by comparing with 2.7.3 and 2.0.0, I think there's something wrong now.
    with 16 threads on a 8 max pool size, 
    the 2.0.0 could perform very well while the 2.7.3 will see a lot of exceptions if we set the maxwait=20ms;

    https://github.com/xetorthio/jedis/issues/1139

  • 相关阅读:
    微信公众号的开通
    支付宝同步请求检查appid,以及公钥,私钥是否正确
    检查支付宝异步通知是否正确
    支付宝开发者中心添加应用
    js中undefined和null的区别
    判断前端<input>标签是否选中(批量删除时,批量选择复选框)
    P1396 营救+二分+BFS
    P1396 营救+生成树
    P1396 营救+最短路
    P1195 口袋的天空
  • 原文地址:https://www.cnblogs.com/softidea/p/5759447.html
Copyright © 2011-2022 走看看