[
https://issues.apache.org/jira/browse/POOL-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved POOL-279.
------------------------------
Resolution: Fixed
Fix Version/s: 2.3
Sebb's proposed code patch and slightly revised version of Jacopo's test
committed in r1647206. I tested fairly extensively using GOP borrow/return
sequences in place of the direct allocate/deallocate and was not able to get a
failure. I am pretty sure it is not possible for this to happen with actual
pool use, as per comments above the state management will not allow the
interleaving of calls necessary to get a negative value back from
getIdleTimeMillis.
I tried to simplify the test, but was not able to get consistent failures
pre-patch when I pulled out the getIdleTimeMillis calls in the
allocate/deallocate task. I think what may be going on here is synchronization
delays waiting on the system clock are necessary to get the "bad" sequence to
happen. I tried defining a third task that just hit the clock, but was not
able to get the consistent failures that Jacopo's original generates.
> Thread concurrency issue in DefaultPooledObject.getIdleTimeMillis()
> -------------------------------------------------------------------
>
> Key: POOL-279
> URL: https://issues.apache.org/jira/browse/POOL-279
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 2.2
> Reporter: Jacopo Cappellato
> Priority: Minor
> Fix For: 2.3
>
> Attachments: POOL-279-unit-test.patch, POOL-279.patch,
> POOL-279.patch, POOL-279.patch, POOL-279.patch
>
>
> Under unlucky thread concurrency the getIdleTimeMillis() method of
> DefaultPooledObject can return a negative value.
> I have attached a Junit test that fails most of the times and a simple fix,
> that doesn't use synchronization: with this fix the Junit test always succeed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
