commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <>
Subject [jira] [Commented] (POOL-327) GKOP: returnObject does not unblock threads waiting in borrowObject if maxIdle=0
Date Tue, 20 Jun 2017 23:30:00 GMT


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

This message was sent by Atlassian JIRA

View raw message