commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <>
Subject [jira] Commented: (POOL-75) [pool] GenericObjectPool not FIFO with respect to borrowing threads
Date Tue, 19 Feb 2008 02:36:36 GMT


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,

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 (

Thanks again for the patch!

> [pool] GenericObjectPool not FIFO with respect to borrowing threads
> -------------------------------------------------------------------
>                 Key: POOL-75
>                 URL:
>             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.

View raw message