[jira] Updated: (POOL-75) [pool] GenericObjectPool not FIFO with respect to borrowing threads

["Takayuki Kaneko (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/POOL-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Takayuki Kaneko updated POOL-75:
--------------------------------

    Attachment: java4.patch

Hi Phil,

I'm sorry for late replying.

I ran the latest test cases and passed them with my patch.

I added some comments on FairnessSemaphore javadoc.
My patch is bit difficult because multi-threading programming is difficult to comprehend.
But I think it's not so long, then, you can understand my patch easily with additional comment.

...I'm sorry, my English skill is not so good. Please let me know if you need more description of my patch.

IMHO, maxActive should be a hard limit of number of pooled objects.
Because the upper limit is necessary for system resources like database connection limit,
it can't be allowed to overflow.

Regards,

> [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, java4.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.