You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Shunsuke Nakamura (JIRA)" <ji...@apache.org> on 2018/07/20 16:56:00 UTC
[jira] [Updated] (POOL-347) borrowObject waits for maxWaitMillis
over in pool full
[ https://issues.apache.org/jira/browse/POOL-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shunsuke Nakamura updated POOL-347:
-----------------------------------
Description:
Since POOL-303's [fix|https://github.com/apache/commons-pool/commit/a4c544a24242701673073d32d2ddbf037fac0099], even if we specify maxWaitMillis, object creation continues waiting for longer time without any hard limit at [this line|https://git.linecorp.com/LINE-Server/apache-commons-pool2/commit/a4c544a24242701673073d32d2ddbf037fac0099#diff-39748305ad0db35f23449745d04c89fbR1046].
Here's the actual stacktrace:
{code}
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000000741158358> (a java.lang.Object)
at java.lang.Object.wait(Object.java:502)
at org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:848)
- locked <0x0000000741158358> (a java.lang.Object)
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:417)
at org.apache.commons.pool2.impl.TestGenericObjectPool.testReturnBorrowObjectWithingMaxWaitMillis(TestGenericObjectPool.java:2658)
{code}
As example of this issue,
we use Jedis2.9 with commons-pool 2.4.3 and maxWaitMillis=500ms in our environment.
However, when master node is down and Pool is full, successor JedisConnections for dead master wait at the line forever until pool is free.
Therefore, aborting old connections takes 40 ~ 80 sec.
In order to avoid such situations, we should set hard limit to wait by reusing maxWaitMillis or another value.
was:
Since POOL-303's [fix|https://github.com/apache/commons-pool/commit/a4c544a24242701673073d32d2ddbf037fac0099], even if we specify maxWaitMillis, object creation continues waiting for longer time without any hard limit at [this line|https://git.linecorp.com/LINE-Server/apache-commons-pool2/commit/a4c544a24242701673073d32d2ddbf037fac0099#diff-39748305ad0db35f23449745d04c89fbR1046].
Here's the actual stacktrace:
{code}
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000000741158358> (a java.lang.Object)
at java.lang.Object.wait(Object.java:502)
at org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:848)
- locked <0x0000000741158358> (a java.lang.Object)
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:417)
at org.apache.commons.pool2.impl.TestGenericObjectPool.testReturnBorrowObjectWithingMaxWaitMillis(TestGenericObjectPool.java:2658)
{code}
As example of this issue, we use Jedis2.9 with commons-pool 2.4.3 and maxWaitMillis=500ms in our environment.
However, when master node is down and Pool is full, successor connections for dead master wait at the line until pool is free. Therefore, aborting old connections takes 40 ~ 80 sec.
In order to avoid such situations, we should set hard limit to wait by reusing maxWaitMillis or another value.
> borrowObject waits for maxWaitMillis over in pool full
> ------------------------------------------------------
>
> Key: POOL-347
> URL: https://issues.apache.org/jira/browse/POOL-347
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 2.4.3, 2.5.0, 2.6.0
> Reporter: Shunsuke Nakamura
> Priority: Critical
>
> Since POOL-303's [fix|https://github.com/apache/commons-pool/commit/a4c544a24242701673073d32d2ddbf037fac0099], even if we specify maxWaitMillis, object creation continues waiting for longer time without any hard limit at [this line|https://git.linecorp.com/LINE-Server/apache-commons-pool2/commit/a4c544a24242701673073d32d2ddbf037fac0099#diff-39748305ad0db35f23449745d04c89fbR1046].
> Here's the actual stacktrace:
> {code}
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0000000741158358> (a java.lang.Object)
> at java.lang.Object.wait(Object.java:502)
> at org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:848)
> - locked <0x0000000741158358> (a java.lang.Object)
> at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:417)
> at org.apache.commons.pool2.impl.TestGenericObjectPool.testReturnBorrowObjectWithingMaxWaitMillis(TestGenericObjectPool.java:2658)
> {code}
> As example of this issue,
> we use Jedis2.9 with commons-pool 2.4.3 and maxWaitMillis=500ms in our environment.
> However, when master node is down and Pool is full, successor JedisConnections for dead master wait at the line forever until pool is free.
> Therefore, aborting old connections takes 40 ~ 80 sec.
> In order to avoid such situations, we should set hard limit to wait by reusing maxWaitMillis or another value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)