[
https://issues.apache.org/jira/browse/POOL-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901828#comment-17901828
]
SunShuai commented on POOL-418:
-------------------------------
[~ggregory] Thanks for your reply
The documentation for the {{borrowObject}} method states:
{quote}"The length of time that this method will block when
{{getBlockWhenExhausted()}} is true is determined by the value passed into the
{{borrowMaxWaitMillis}} parameter."
{quote}
However, based on current behavior, if the {{create}} method has already waited
for *{{maxWaitMillis}}* without successfully creating a connection, it will
then enter the blocking queue and wait for another {*}full
{{maxWaitMillis}}{*}. This means the maximum wait time for this interface could
reach {*}twice the value of {{maxWaitMillis}}{*}.
My question is: When the {{blockWhenExhausted}} parameter is enabled, should
the remaining wait time be recalculated to ensure consistency with the
documentation?
> 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
>
> Attachments: 74C00A2F-EE3A-4660-BE58-66CA37F9808A.png,
> EE4BD798-26B6-4AE1-B114-5AC7342B31A6.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)
