[ http://issues.apache.org/jira/browse/POOL-87?page=comments#action_12441750 ] Sandy McArthur commented on POOL-87: ------------------------------------
Poolable Objects created by makeObject() are considered to be an active state so they do not need to be activated again. I'll admit the class Javadoc for PoolableObjectFactory is a bit vague but the method Javadocs are more clear: activateObject: "Reinitialize an instance to be returned by the pool." makeObject: "Creates an instance that can be returned by the pool." If you didn't design your PoolableObjectFactory to work this way you can probably call activateObject at the end of your makeObject method. The reason for this behavior is for performance and keeping the code from being too ugly. When you are making a new poolable object you *may* not need to do as much work getting it ready to be used. For example, when pooling a StringBuffer a new StringBuffer is ready to go. A recycled one will need to be cleared to make it ready for reuse. As for code complexity, when you are borrowing an idle object, the pool loops though available idle objects and tries to activate them. If the activateObject method throws an exception, that exception is swallowed because it is assumed the pool can recover from one bad object and the problem idle object is destroyed and another idle object is attempted to be activated. This repeats until there are no more idle objects to try to activate and then a new object will be made with makeObject. Exceptions thrown by makeObject are not swallowed by the pool as they indicate a problem the pool cannot recover from. Writing the pool so it keeps track if the object is from the idle pool or newly made by makeObject and having different exception throwing behavior depending on when the object came from is ugly, error prone, tends to dupe a lot of code and proably less likely to optimized by hotspot. Hope that helps clear things up. Please respond if you still think there is a bug, else I'll close this issue in a few days. (Also, the PooledObject.passivateObject() method in the submitted unit test had a bug. The assignment to passivateObjectCalled should be "true" not "false".) > Commons-Pool does not always calling activateObject on newly created Objects > ---------------------------------------------------------------------------- > > Key: POOL-87 > URL: http://issues.apache.org/jira/browse/POOL-87 > Project: Commons Pool > Issue Type: Bug > Environment: Windows 2003 Java HotSpot(TM) Client VM (build > 1.5.0_08-b03, mixed mode, sharing) > Reporter: Bernie McGourty > Attachments: TestGenericObjectPool.java > > > I'm using the GenericObjectPool and a PoolableObjectFactory. > The GenericObjectPool works as expected and documented in that my > implementation of the PoolableObjectFactory is called according to the > life-cycle: > 1. makeObject is called whenever a new instance is needed. > 2. activateObject is invoked on every instance before it is returned from the > pool. > 3. passivateObject is invoked on every instance when it is returned to the > pool. > 4. destroyObject is invoked on every instance when it is being "dropped" from > the pool (whether due to the response from validateObject, or for reasons > specific to the pool implementation.) 5. validateObject is invoked in an > implementation-specific fashion to determine if an instance is still valid to > be returned by the pool. It will only be invoked on an "activated" instance. > I've set the minimum idle instances to 5 and when the pool goes below 5 > instances, new objects are created to reach the minimum. > The problem is that the life-cycle is not followed in that makeObject is > called on the PoolFactory and then validateObject - activateObject is never > called. > The interface doc for validateObject stipulates that it will only be invoked > on "activated" objects. > I looked at the GenericObjectPool class and it appears that ensureMinIdle() > creates the new objects required by calling addObject() but when it calls > addObjectToPool() the newly created object is never activated before it is > validated. > I'm using the following pool config: > poolConfig.maxWait = 5000; > poolConfig.maxActive = 100; > poolConfig.minIdle = 5; > poolConfig.maxIdle = 50; > poolConfig.testOnBorrow = true; > poolConfig.testOnReturn = true; > poolConfig.testWhileIdle = true; > poolConfig.timeBetweenEvictionRunsMillis = 15000; > poolConfig.whenExhaustedAction = GenericObjectPool.WHEN_EXHAUSTED_GROW; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
