commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <>
Subject Re: [POOL] a conceptual implementation error?
Date Mon, 20 Nov 2006 23:02:13 GMT
On 11/20/06, Tom <> wrote:
> >> Currently the StackedObjectPool goes into a very CPU consuming
> >> busy-waiting loop
> >
> > If you can create an issue with some sample code that pegs the CPU
> > with StackObjectPool when it should be wait()ing I'd appreciate it
> > because that would be a bug that needs to be fixed by the next
> > release.
> It's simple to do: create PoolableObjectFactory that returns null on
> borrowObject and then create a StackObjectPool. The code below will have
> the CPU go to 100%. Enjoy :-)
> public class Test implements PoolableObjectFactory
> {
>     public Object makeObject() throws Exception
>     {
> System.out.println("makeObject");
>         return null;
>     }

This is a nonsensical PoolableObjectFactory. The makeObject has no
reason to return null. Either return a poolable object ready for use
or throw an Exception indicating why a poolable object could not be

I'll admit the Javadocs for PoolableObjectFactory.makeObject does not
explicitly state that returning null from the method is prohibited but
that is implicit in it's affirmative statement that makeObject returns
"an instance that can be returned by the pool." See:

> Now, I've been thinking in the car a bit more on this one. One could say
> that if the pool is infinite, it is not possible to initialize it with
> all possible values, therefore a factory is needed. In this case there
> is no BLOCK or FAIL amn GROW is default. If the pool is finite, then all
> possible values can be entered into the pooled set and there is no need
> for an unpooled set (factory). BLOCK and FAIL only need to be implement
> on the pooled set. This would closely match the current implementation,

Like any other library, it will be maximally effective if it you use
the library as it is intended. Pool provides a general purpose object
pooling api. The expectations are that the poolable objects are
interchangeable, reusable, and the lifecycle of poolable objects are
to be managed by the PoolableObjectFactory. Also to a lesser extent is
is expected that poolable objects are expensive to create and not
thread-safe else the performance reasons for using a pool are
mitigated. I'm not sure what you are trying to do but I think you are
trying hard to make a square peg fit in a round hole.

> but this would also mean that the pools should provide an easy mechanism
> for initial filling.

Pools are designed so that they lazily create poolable objects as
needed via the makeObject method. This helps elimiate a slow
application start up time and doesn't do more work that is actually
needed. If you feel you need to prefill your pool a utility method is
provided that does just that in PoolUtils.prefill:,%20int)

> So:
> - infinite = factory, GROW, no BLOCK / FAIL, maxActive, maxIdle, etc
> - finite = no factory, initial filling, no GROW, BLOCK/FAIL, no
> maxActive, no maxIdle, etc

Using a pool without a PoolableObjectFactory is *strongly
discouraged*. It barely works only for backwards compatibility
reasons. Using a pool without a PoolableObjectFactory is prohibited in
the new pool implementations that will be available in the release of
Pool 2.0.

> I have written an alternative implementations using the same ObjectPool
> and PoolableObjectFactory interfaces.

If one of the provided pool implementations doesn't meet your needs
then writing your own implementation is what you should do.

Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

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

View raw message