commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (POOL-279) Thread concurrency issue in DefaultPooledObject.getIdleTimeMillis()
Date Thu, 09 Oct 2014 01:06:33 GMT

    [ 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)

Mime
View raw message