commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (POOL-75) [pool] GenericObjectPool not FIFO with respect to borrowing threads
Date Sun, 17 May 2009 16:33:45 GMT

    [ https://issues.apache.org/jira/browse/POOL-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710205#action_12710205
] 

Mark Thomas commented on POOL-75:
---------------------------------

The recent changes to pool mean that this patch won't apply cleanly. There are also some things
areas where I felt it could be improved. In particular:
- the FairnessSemaphore class seems to be duplicating some of the GOP functionality
- the same changes need to be made for GKOP as well as GOP.
- the test case isn't included.

I have taken some of the ideas from this patch and implemented an alternative solution for
GOP. Test case and patches to follow. I'll then look at porting the changes to GKOP.

Although I'm not using the patch exactly as is, many thanks for providing it as helped considerably
as I was looking at options to implement a fix for this issue.

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


Mime
View raw message