commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur (JIRA)" <>
Subject [jira] Commented: (POOL-75) [pool] GenericObjectPool not FIFO with respect to borrowing threads
Date Fri, 09 Jun 2006 01:00:32 GMT
    [ ] 

Sandy McArthur commented on POOL-75:

After having slept on it and since thread fairness only makes sense in the WHEN_EXHAUSTED_BLOCK
case I think the best plan is to:

1. Patch GenericObjectPool instead of creating a subclass. GOP is a bit of a hair ball but
I think adding one more configurable feature is less hairy than exposing more of it's internals
to allow subclassing. Personally, I think GOP is really dangerous to extend as use of it in
that way wasn't well thought out as it was patched over the years and I don't want to encourage
that kind of use as it's so fragile.

Also, I don't think the setting "use fair queueing" feature should be added to the constructors.
They are unwieldily enough already and I've fixed few bugs due to the confusing nature of
keeping the parameters straight. Just let it be controlled via a setter method, no need to
add another constructor that will take 14 parameters, though I do think it should be added
to the GOP.Config class.

2. I think all or most all of the thread fairness can be implemented in the WHEN_EXHAUSTED_BLOCK
case of the switch statement. This would keep the scope of the changes as narrow as possible.

3. Since the evictor sometimes adds idle objects to the pool, despite it's name, I don't think
it should get in line like the other threads as that could slow everything down.

If you want to rework the patch then go for it, else I'll eventually get to it before the
2.0 release.

> [pool] GenericObjectPool not FIFO with respect to borrowing threads
> -------------------------------------------------------------------
>          Key: POOL-75
>          URL:
>      Project: Commons Pool
>         Type: Improvement

>     Versions: Nightly Builds
>  Environment: Operating System: All
> Platform: All
>     Reporter: Gordon Mohr
>     Assignee: Sandy McArthur
>     Priority: Minor

> 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.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message