DO NOT REPLY [Bug 14983] New: - GenericObjectPool should allow for manual population of the pool

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14983>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14983

GenericObjectPool should allow for manual population of the pool

           Summary: GenericObjectPool should allow for manual population of
                    the pool
           Product: Commons
           Version: 1.0.1 Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Pool
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: sschwell@yahoo.com


I need an ObjectPool which blocks when exhausted and is populated manually by 
the client. Wouldn't it be nice if GenericObjectPool provided this? I don't 
see how adding this capability would detract from any existing functionality. 
All we need is a new method, addNewObject(), whose implementation is very 
similair to, but NOT the same as, returnObject().

Also, the factory should be truly optional. it makes the class more flexible, 
without any sacrifice in functionality. the current implementation which 
allows construction of a GenericObjectPool without a factory, but throws 
NullPointerException when used, is broken. There's no way that can be 
considered robust code.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

[pool] Re: GenericObjectPool should allow for manual population of the pool

[Jeffrey Varszegi <je...@generalize.net>]

You're right-- I've had the same thought for a little
while now.  There should also be a method to check
something out of the pool permanently (so that the
removed object doesn't count against the pool's
maximum), in case some process would like to hold onto
a connection or something similar for a long time, and
would like to assume all responsibility for the
object.
This could be an optional operation, or a strategy
could be settable...

(Some of the) other weaknesses I think should be
addressed in the pool package:

1. Unintuitive naming makes the code hard to reuse for
people that didn't write it

2. There's no way to set a minimum number of 'idle'
objects

3. The WHEN_EXHAUSTED_GROW strategy: there's nothing
provided by this that isn't provided by setting an
infinite maximum 'active' size

4. Dependencies on things like CursorableLinkedList
that aren't really necessary make the pools tougher
for end users to just drop into their code

5. Failure to synchronize on a hidden monitor means
that an outside process can indefinitely lock
implementations like GenericObjectPool

6. The 'factory' (which isn't really a factory, but a
full lifecycle manager) is necessarily involved in all
steps of GenericObjectPool, but there isn't full
support for its use.  For instance, the fact that a
'factory' has an activateObject() method doesn't mean
it should be called every time an object is gotten
from the pool; this strategy should be settable at the
pool level.  There are numerous good reasons for this,
not least of them being that in an environment where
high availability is most important, it might be
desirable NEVER to passivate a pooled object, even if
it's possible.

7. Class GenericObjectPool.Config provides no extra
functionality

8. Callers of methods that acquire objects from the
pool should be able to provide their own timeouts

There are a few other things I've noticed as well. 
I'm not slamming anyone or any code, but inviting
comment.  I think that with some touching up, the pool
package can be really good.

Jeff

--- bugzilla@apache.org wrote:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> 
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE
> AT
>
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14983>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED
> AND 
> INSERTED IN THE BUG DATABASE.
> 
>
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14983
> 
> GenericObjectPool should allow for manual population
> of the pool
> 
>            Summary: GenericObjectPool should allow
> for manual population of
>                     the pool
>            Product: Commons
>            Version: 1.0.1 Final
>           Platform: Other
>         OS/Version: Other
>             Status: NEW
>           Severity: Normal
>           Priority: Other
>          Component: Pool
>         AssignedTo: commons-dev@jakarta.apache.org
>         ReportedBy: sschwell@yahoo.com
> 
> 
> I need an ObjectPool which blocks when exhausted and
> is populated manually by 
> the client. Wouldn't it be nice if GenericObjectPool
> provided this? I don't 
> see how adding this capability would detract from
> any existing functionality. 
> All we need is a new method, addNewObject(), whose
> implementation is very 
> similair to, but NOT the same as, returnObject().
> 
> Also, the factory should be truly optional. it makes
> the class more flexible, 
> without any sacrifice in functionality. the current
> implementation which 
> allows construction of a GenericObjectPool without a
> factory, but throws 
> NullPointerException when used, is broken. There's
> no way that can be 
> considered robust code.
> 
> --
> To unsubscribe, e-mail:  
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>