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