[
https://issues.apache.org/jira/browse/POOL-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Takayuki Kaneko updated POOL-75:
--------------------------------
Attachment: java2.patch
I revised my patch.
* integrated with GenericObjectPool, which means removing duplicated
operations around maxActive.
* fixed a problem around maxWait handling.
As a result, GenericObjectPool#borrowObject is simpler.
> [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.
