search

redis / jedis

Redis Java client
https://redis.github.io/jedis/
MIT License
11.89k stars 3.87k forks source link

The maximum wait time for acquiring a resource from the Jedis Pool may exceed expectations. #4014

Open gududesundapao opened 2 weeks ago

gududesundapao commented 2 weeks ago

Hello ！

Expected behavior

If the number of connections currently being created has reached the maxTotal, subsequent threads waiting to create connections will wait for a maxWaitMillis time, as the connections currently being created might fail.

We expect the waiting time not to exceed maxWaitMillis time, as this parameter affects our estimation of the overall time taken by the interface.

Actual behavior

But in situations where the connection is tight, the waiting time can be up to twice the maxWaitMillis consumption.

Steps to reproduce:

  1. Reduce the maximum number of connections
  2. Using Linux TC mechanism to cause TCP communication timeout
  3. Observe the maximum waiting time

We have found that in some special cases, when creating connections from a connection pool, there may be excessively long waiting times

code: redis.clients.jedis.JedisPool#getResource -> redis.clients.jedis.util.Pool#getResource -> org.apache.commons.pool2.impl.GenericObjectPool#borrowObject(long) -> org.apache.commons.pool2.impl.GenericObjectPool#create

image

image

The thread that failed to create the connection will wake up the thread that is waiting to be created. Threads that do not compete for resources will wait again, and the waiting time will still be the maxWaitMillis. unbelievable！ If the first waiting time is ( maxWaitMillis - 1ms ), plus the second full waiting time, then the full waiting time will be twice the expected time.

The waiting time we hope for this time is the total waiting time minus the time already waited

We are not sure if this issue has been addressed and look forward to your reply

Redis / Jedis Configuration

redis-client.timeout=100 redis-client.pool.maxTotal=1 redis-client.pool.maxIdle=1 redis-client.pool.minIdle=1 redis-client.pool.testOnBorrow=false redis-client.pool.testWhileIdle=true redis-client.pool.timeBetweenEvictionRunsMillis=30000 redis-client.pool.minEvictableIdleTimeMillis=1800000 redis-client.pool.numTestsPerEvictionRun=3 redis-client.pool.softMinEvictableIdleTimeMillis=-1 redis-client.pool.blockWhenExhausted=true redis-client.pool.maxWaitMillis=80

Jedis version:

3.6.3

apache commons-pool2 version:

2.9.0

Redis version:

Java version:

1.8

sazzad16 commented 2 weeks ago

@gududesundapao First of all, thank you for using Jedis.

Jedis is dependent on Apache Commons Pool. This is also evident from the source code you have provided because those are from that library. You may try their user mailing list. You may even try their developer mailing list if you have some idea about solving the issue.

Thank for understanding.