commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom <>
Subject Re: [POOL] a conceptual implementation error?
Date Mon, 20 Nov 2006 21:51:38 GMT

> What version of Pool are you using? Please make sure you are using
> Pool 1.3 or a nightly build that will likely become Pool 2.0
> semi-soon:


>> 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 :-)

import org.apache.commons.pool.PoolableObjectFactory;
import org.apache.commons.pool.impl.StackObjectPool;

public class Test implements PoolableObjectFactory
    public void activateObject(Object arg0) throws Exception

    public void destroyObject(Object arg0) throws Exception

    public Object makeObject() throws Exception
        return null;

    public void passivateObject(Object arg0) throws Exception
    public boolean validateObject(Object arg0)
        return true;

    public static void main(String[] args)
            Test lTest = new Test();
            StackObjectPool lStackObjectPool = new StackObjectPool(lTest);
        catch (Throwable t) {t.printStackTrace(); }

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, 
but this would also mean that the pools should provide an easy mechanism 
for initial filling.

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

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


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

View raw message