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://*.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