[
https://issues.apache.org/jira/browse/HDFS-6355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13995358#comment-13995358
]
Colin Patrick McCabe commented on HDFS-6355:
--------------------------------------------
bq. Here since we already use monotonicNow(), which is relative to jvm startup,
I don't think we will get a negative value here and hence no need to take a
max(..).
The issue is that {{currentPeriodStart}} is not going to increase over the
course of a scan, but {{Time.monotonicNow}} will. So eventually, that quantity
could become negative. This is certainly a corner case (a very, very slow
scan?) but it seems better to handle it.
bq. +1
thanks, will commit later today if there's no more comments
> Fix divide-by-zero, improper use of wall-clock time in BlockPoolSliceScanner
> ----------------------------------------------------------------------------
>
> Key: HDFS-6355
> URL: https://issues.apache.org/jira/browse/HDFS-6355
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.4.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HDFS-6355.001.patch
>
>
> BlockPoolSliceScanner uses {{Time.now}} to calculate an interval. But this
> is incorrect, since if the wall-clock time changes, we will end up setting
> the scan periods to a shorter or longer time than we configured.
> There is also a case where we may divide by zero if we get unlucky, because
> we calculate an interval and divide by it, without checking whether the
> interval is 0 milliseconds. This would produce an {{ArithmeticException}}
> since we are using longs.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
