commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (POOL-347) borrowObject waits for maxWaitMillis over in pool full
Date Sat, 21 Jul 2018 22:35:00 GMT

    [ https://issues.apache.org/jira/browse/POOL-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16551840#comment-16551840
] 

ASF GitHub Bot commented on POOL-347:
-------------------------------------

Github user sunsuk7tp commented on the issue:

    https://github.com/apache/commons-pool/pull/10
  
    Hmm.. I tried many times but it always succeeded like below: 
    https://gist.github.com/sunsuk7tp/c6ad1c73c77403c32bab546ca86198ff
    
    Also, test all passed on travis ci: 
    https://travis-ci.org/apache/commons-pool/builds/406334648?utm_source=github_status&utm_medium=notification
    
    I guess `mvn clean` somehow doesn't work well in your local because the cause is `java.lang.NoSuchMethodError`.
BTW do you get same error even if you get rid of new test case from my patch? 


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