[
https://issues.apache.org/jira/browse/POOL-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925305#comment-17925305
]
Gary D. Gregory commented on POOL-418:
--------------------------------------
[~sunshuai]
I pushed to git master with improvement, you can also use a 2.12.2-SNAPSHOT
build from https://repository.apache.org/content/repositories/snapshots/
Please try your suggestion in the code and you'll see some failing tests: The
suggestion causes the timeout to be ignored and the pool waits until an entry
is available, which is the opposite of the desired behavior. You should
generally try ideas in code and PR.
TY!
> The maximum wait time for GenericObjectPool.borrowObject(*) may exceed
> expectations due to a spurious thread wakeup
> -------------------------------------------------------------------------------------------------------------------
>
> Key: POOL-418
> URL: https://issues.apache.org/jira/browse/POOL-418
> Project: Commons Pool
> Issue Type: Bug
> Reporter: SunShuai
> Assignee: Gary D. Gregory
> Priority: Minor
> Fix For: 2.12.1, 2.12.2
>
> Attachments: 74C00A2F-EE3A-4660-BE58-66CA37F9808A.png,
> EE4BD798-26B6-4AE1-B114-5AC7342B31A6.png, Snipaste_2025-02-07_17-05-08.png
>
>
> I found an issue when using jedis to operate Redis database, Here is the
> issue link -> [https://github.com/redis/jedis/issues/4014]. we feel that it's
> a problem with the Commons pool.
>
> In situations where the connection is tight, the waiting time can be up to
> twice the maxWaitMillis consumption.
> code: 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.
> 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.
>
> such as: Duration remainingWait =
> localMaxWaitDuration.minus(Duration.between(localStartInstant,
> Instant.now()));
> if (remainingWait.isNegative()) {
> create = Boolean.FALSE;
> } else {
> wait(makeObjectCountLock, remainingWait);
> }
>
> We are not sure if this issue has been addressed and look forward to your
> reply.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
