DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=33591>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 ------- Additional Comments From [EMAIL PROTECTED] 2006-03-08 06:16 ------- James, the testPoolableConnectionLeak() in "Possible testcase to illustrate bug" has a problem I think. GenericObjectPool (and any non-custom ObjectPool) doesn't have any special knowledge about objects borrowed from it. That test cased: 1. borrows an object from the pool, in this case a Connection instance 2. closes said Connection 3. asks the pool again how many objects were borrowed from it The ObjectPool.getNumActive() method simply returns how many objects were returned from ObjectPool.borrowObject() minus how many were returned with ObjectPool.returnObject(...) or were invalidated with ObjectPool.invalidateObject(...) For the ObjectPool to return the right value for getNumActive() you should invalidate the connection by adding a pool.invalidateObject(conn); just before the assertEquals(). Now the added pool.invalidateObject(conn); line does thown an exception and it really shouldn't. The point of the ObjectPool.invalidateObject(...) method is that the object being invalidated is in a broken state and the PoolableObjectFactory.destroyObject(...) method should be prepared for anything. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
