[
https://issues.apache.org/jira/browse/POOL-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13974945#comment-13974945
]
Phil Steitz commented on POOL-263:
----------------------------------
The statement "once the pool is closed" means once the close method completes.
At that time, subsequent returns will result in objects being destroyed. If a
return happens while close is executing it is possible for an instance to
return between the time close begins and the (volatile) closed property is set.
In that case, the returning instance is likely to be destroyed by the clear()
call at the end of close(). It does not look possible to me for an instance to
sneak in after clear() has begun because closed is set before clear is invoked
and clear's polling would pick up the returning instance. If someone can
produce a test case indicating that it is actually possible to orphan instances
this way, we can look at options for ensuring clear() on close is really
effective; otherwise I am inclined to close this as invalid.
> GenericObjectPool close and returnObject is not synchronized
> ------------------------------------------------------------
>
> Key: POOL-263
> URL: https://issues.apache.org/jira/browse/POOL-263
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: ALL
> Reporter: yangxuesong
>
> the javadoc on GenericObjectPool#close() says:
> "Closes the pool. Once the pool is closed, borrowObject() will fail with
> IllegalStateException, but returnObject(Object) and invalidateObject(Object)
> will continue to work, with returned objects destroyed on return.
> Destroys idle instances in the pool by invoking clear()."
> Thread1: pool.close()
> Thread2: pool.returnObject()
> since close and returnObject is not synchronized, there is a small chance
> that an returned object is not destoryed after the pool is closed
--
This message was sent by Atlassian JIRA
(v6.2#6252)
