You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
JedisPooled is very convenient because you can just issue commands without having to do a try-with-resources for every call.
When using a pipeline, try-with-resources is still necessary. But, if a socket exception occurs, the pipe is closed but the connection is not returned to the pool, so with enough exceptions, the pool is exhausted.
To reproduce, I ran a local redis server and then ran this Groovy script:
importredis.clients.jedis.JedisPooled
var pool =neworg.apache.commons.pool2.impl.GenericObjectPoolConfig<redis.clients.jedis.Connection>()
pool.maxTotal=4
pool.maxWait=java.time.Duration.ofMillis(200)
def redis =newJedisPooled(pool, 'localhost', 6379)
def log =org.slf4j.LoggerFactory.getLogger("demo")
while (true) {
try (var pipe = redis.pipelined()) {
println pipe.smembers('currencies')
println"POOL max ${redis.pool.maxTotal} active ${redis.pool.numActive}"
} catch (RuntimeException ex) {
log.error("oops, something went wrong", ex)
println"POOL max ${redis.pool.maxTotal} active ${redis.pool.numActive}"
}
Thread.sleep(2000)
}
This will print active connections as 1. Then stop the server, and let the script show an exception; start the server again, and now it will display active connections as 2; you can repeat this until the pool is exhausted and the error changes from JedisConnectionException saying "unexpected end of stream" to a JedisException caused by a NoSuchElementException thrown by the pool.
I have managed to avoid this by enabling borrowOnTrue setting on the pool, but this causes some overhead which is undesirable. I believe the JedisPooled should catch the socket exceptions and discard the connection so the pool can create a new one when needed.
The text was updated successfully, but these errors were encountered:
@chochos I am also facing something similar issue here, can you please check this discussion thread - #4028 and confirm that it's because of the above issue and upgrading the jedis to 5.2.0 could help in resolving the issue TIA.
JedisPooled is very convenient because you can just issue commands without having to do a try-with-resources for every call.
When using a pipeline, try-with-resources is still necessary. But, if a socket exception occurs, the pipe is closed but the connection is not returned to the pool, so with enough exceptions, the pool is exhausted.
To reproduce, I ran a local redis server and then ran this Groovy script:
This will print active connections as 1. Then stop the server, and let the script show an exception; start the server again, and now it will display active connections as 2; you can repeat this until the pool is exhausted and the error changes from JedisConnectionException saying "unexpected end of stream" to a JedisException caused by a NoSuchElementException thrown by the pool.
I have managed to avoid this by enabling borrowOnTrue setting on the pool, but this causes some overhead which is undesirable. I believe the JedisPooled should catch the socket exceptions and discard the connection so the pool can create a new one when needed.
The text was updated successfully, but these errors were encountered: