[ https://issues.apache.org/jira/browse/POOL-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16056666#comment-16056666 ]
Phil Steitz commented on POOL-327: ---------------------------------- Its nice to have test cases and patches to look at. Nice work, Paul! The first patch should resolve the issue as presented and I don't see anything wrong with it, though its been a while since I worked on that code. The second is a more general solution that is probably also OK. I have two comments though. 1. Going back to POOL-240, my gut is we are playing whack-a-mole here to avoid addressing the core problem of just notifying the waiting threads when something happens that should enable them to progress. This is a vague statement and it could be the ensureMinIdle approach is just fine. I just think it is worth revisiting. 2. An WONT_FIX argument could be made here. minIdle = 0 smells like a questionable use case for GOP. And the ensureMinidle workaround kind of abuses the fuzzy accounting that allows you to in fact push a new but "idle" instance through the pool to give to a waiting thread. > GKOP: returnObject does not unblock threads waiting in borrowObject if > maxIdle=0 > -------------------------------------------------------------------------------- > > Key: POOL-327 > URL: https://issues.apache.org/jira/browse/POOL-327 > Project: Commons Pool > Issue Type: Bug > Affects Versions: 2.4.2 > Reporter: Paul Pazderski > Priority: Minor > Attachments: 327-maxIdle0-alternativ.patch, 327-maxIdle0.patch, > 327-maxIdle0-test.patch > > > If idle objects are disabled by maxIdle=0 a thread blocked in borrowObject is > not notified if another thread returns an object. > Attached is a unit test (327-maxIdle0-test.patch) that demonstrates the > issue. I tried a similar test on GenericKeyedObjectPool as well which not > seems to be affected by this issue. > I also attached two possible solutions for this issue. > The first (327-maxIdle0.patch) just notifies a potentially waiting thread in > the affected returnObject code branch. (similar to POOL-240) > The second (327-maxIdle0-alternativ.patch) checks for waiting threads every > time an object get destroyed. But this may introduce undesired behavior in > other functions. (like clear or evict) -- This message was sent by Atlassian JIRA (v6.4.14#64029)