commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (POOL-327) GKOP: returnObject does not unblock threads waiting in borrowObject if maxIdle=0
Date Wed, 21 Jun 2017 17:28:00 GMT

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

Phil Steitz edited comment on POOL-327 at 6/21/17 5:27 PM:
-----------------------------------------------------------

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.  maxIdle = 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.



was (Author: psteitz):
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)

Mime
View raw message