[
https://issues.apache.org/jira/browse/POOL-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572019#action_12572019
]
Phil Steitz commented on POOL-75:
---------------------------------
Thanks, Takayuki.
I just committed a change to the address the failure you mention in 1). This
is the result of what is at best an undocumented feature, but may be a bug in
the current code's enforcement of the maxActive property. As you can see from
the current implementation of borrowObject, if there are idle objects in the
pool, borrowObject always succeeds - even if maxActive is exceeded. The latter
can happen if addObject is invoked via the public API when there are instances
checked out. That is what the test case does. addObject does no numActive
check, though it does check maxIdle.
Unfortunately, changing behavior so that either addObject fails to add more
than maxActive instances or borrowObject fails when idle instances are
available in the pool will likely break some client applications, which like
the test case above take advantage of the fact that you can inflate the pool
using addObject. So we may need to work around this or at least discuss it
some more. Part of the problem is that the documentation of maxActive as it
stands now is weak and arguably ambiguous. This needs to be improved in any
case.
Thanks again for the patch. I agree that getting fairness to work is a big
plus. As I said above, some class javadoc for FairnessSemaphore would be good.
Also, description of how exactly maxActive, maxWait, etc are enforced after
the patch would be useful. I will complete review in the next couple of days.
Comments from other interested parties welcome!
> [pool] GenericObjectPool not FIFO with respect to borrowing threads
> -------------------------------------------------------------------
>
> Key: POOL-75
> URL: https://issues.apache.org/jira/browse/POOL-75
> Project: Commons Pool
> Issue Type: Improvement
> Affects Versions: Nightly Builds
> Environment: Operating System: All
> Platform: All
> Reporter: Gordon Mohr
> Priority: Minor
> Fix For: 1.5
>
> Attachments: ctest.fairness.png, ctest.original.png, java.patch,
> java2.patch, java3.patch
>
>
> GenericObjectPool has recently been made FIFO with respect to the managed pool
> objects -- however, it is still not FIFO with respect to threads requesting
> those objects. Specifically, because standard non-fair Java synchronization
> monitors are used, later threads may barge ahead of earlier threads that are
> already waiting for a pool object to become available. At its extreme, some
> threads can cycle objects through the pool many times while others wait
> interminable.
> Not every application needs FIFO fairness with respect to threads, and such
> fairness implies an overhead, so it need not be the default behavior, but it
> would be a valuable option where many threads are sharing a smaller number of
> pool objects.
> I can submit a FairGenericObjectPool which achieves thread-fairness; it only
> requires small changes to GenericObjectPool which allow some subclass
> overriding.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
