commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shunsuke Nakamura (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (POOL-347) borrowObject waits for maxWaitMillis over in pool full
Date Tue, 24 Jul 2018 22:10:00 GMT

     [ 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://github.com/apache/commons-pool/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 the connection pool for the node is full, succeeding
JedisConnections wait there forever until pool is free. 
Therefore, borrowObject (and the aborting) of last connections takes 40 ~ 80 sec at worst
case.

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 the connection pool for the node is full, succeeding
JedisConnections wait there forever until pool is free. 
Therefore, borrowObject (and the aborting) of last connections takes 40 ~ 80 sec at worst
case.

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
>             Fix For: 2.6.1
>
>
> 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://github.com/apache/commons-pool/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 the connection pool for the node is full, succeeding
JedisConnections wait there forever until pool is free. 
> Therefore, borrowObject (and the aborting) of last connections takes 40 ~ 80 sec at worst
case.
> 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)

Mime
View raw message