[
https://issues.apache.org/jira/browse/POOL-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14164510#comment-14164510
]
Sebb commented on POOL-279:
---------------------------
Thanks for the test cse - very useful.
I can confirm that the unit test exposes the bug (MacOSX/Java 6) and that
taking a copy of lastReturnTime before the subtraction fixes the issue. Also,
if the volatile attribute is dropped from the field, the bug returns.
I did not test the case where System.currentTimeMillis() is non-monotonic.
> 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
> 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)
