[
https://issues.apache.org/jira/browse/POOL-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159512#comment-14159512
]
Sebb commented on POOL-279:
---------------------------
Thanks, but it does not really explain why the time can be negative.
AFAICT the problem is that the calculation:
bq. return System.currentTimeMillis() - lastReturnTime;
will first fetch the current time, and then fetch lastReturnTime.
However this may have been updated in the meantime to a later time, hence the
negative value.
Also, as has been pointed out on the dev list, there is a multi-threading issue
- the field is not safely published, so it needs to be made volatile
> 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.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)
