[
https://issues.apache.org/jira/browse/POOL-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570080#action_12570080
]
Phil Steitz commented on POOL-75:
---------------------------------
Thanks for the patch and sorry it took a while to look into it.
I like the ideas in the java2.patch and am interested in working on this.
There are however a couple of problems with the patch, as is. Below all
comments refer to the second patch, java2.patch
1) Multiple unit tests fail when the patch is applied. Let me know if you need
help getting set up to run the pool unit tests. At least one failure is due to
the missing break statement in setWhenExhaustedAction (after the
WHEN_EXHAUSTED_FAIL case). I think there is also a missing release in
borrowObject just before "return pair.value" after activating an object to
return. I am not sure I understand exactly the semantics of acquire and
release, though, so this could be wrong. In any case, we need the unit tests
to pass (or to understand why they are in error if this is the case).
2) I don't follow exactly how the size and depth fields in FairnessSemaphore
are supposed to work. Some class javadoc for this class explaining exactly
what its contract is would help. I am not sure that the relationship between
the pool's maxActive property and the size property of FairnessSemaphore is
correct, though it is quite possible that I just don't understand how
FairnessSemaphore works.
3) FairnessSemaphore needs ASF license header (like on all the other source
files) and we need confirmation that the contribution *can* be made according
to the Apache Contributor's License Agreement
(http://www.apache.org/licenses/#clas)
Thanks again for the patch!
> [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
>
>
> 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.
