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

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

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

AD_LB (Jira)

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

Takayuki Kaneko updated POOL-75:

    Attachment: ctest.fairness.png


I made the patch of fairness connection pool for trunk.

I ran tests with following settings.
 - maxActive = 100
 - each thread holds connection for 10 ms
 - 300 threads runs cuncurrently

I got the good record of this patch.

dbcptype, throughput,  Ave.,     Var.,  S.D. , min., 50%, 60%, 70%, 80%, 90%, max.
original,     8533.9, 35.27, 18488.62, 135.97,   10,  12,  12,  12,  12,  13, 3527
fairness,     8744.2, 34.43,    18.87,   4.34,   10,  34,  34,  34,  35,  36,  160

"original" has a problem about fairness. maximum time of getting connection is 3527 ms
regardless of each threads holds connection for 10 ms.

I put 2 graphs that showed response time of borrowObject.

> [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: 2.0
>         Attachments: adult-sex.html, ctest.fairness.png, ctest.original.png, java.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.