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

[gududesundapao]

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

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]

@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.

[garydgregory]

See also https://issues.apache.org/jira/browse/POOL-418

[gududesundapao]

@sazzad16 hello
Commos pool has fixed this issue，Does Jedis have a repair plan?
Thanks again

[sazzad16]

@gududesundapao The fix is not released yet. If you really need it, you may consider building the commons-pool library from their source code.

@garydgregory Do you have any tentative date for commons-pool 2.12.1 ?

[garydgregory]

I have 2 other releases in Commons in progress. I'd like to clear the decks before I do another.

[garydgregory]

I will get to this later today.

[garydgregory]

FYI, the Apache Commons Pool 2.12.1 release candidate is open for review and voting here:
https://lists.apache.org/thread/9cz67om5c2dktnlxwkt3b33lw2nmjzob

[sazzad16]

@garydgregory Thank you for the release.

@gududesundapao Jedis dependencies are updated with the fixed version commons-pool. The update can be found in latest snapshot releases of Jedis.