[
https://issues.apache.org/jira/browse/HADOOP-11182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14171347#comment-14171347
]
Ravi Prakash commented on HADOOP-11182:
---------------------------------------
Hi Sascha! Thanks a lot for all your effort!
That -1 release audit warning is probably because you haven't included the
Apache license at the top of the new file you have introduced
(TestGraphiteSink.java). By the way, there already was a file
(TestGraphiteMetrics.java) . Could the test not have been added to that? In
fact you are right, this patch was probably small enough that fixing the test
which failed (TestMetricsSystemImpl) in the earlier patch would have been
enough.
You are right about the 404. As a workaround you can check the console output
or run test-patch yourself. The findbugs warning seems to be coming from a file
not in this patch so we shouldn't have to worry about it.
I can't +1 a patch that I have uploaded.
> GraphiteSink emits wrong timestamps
> -----------------------------------
>
> Key: HADOOP-11182
> URL: https://issues.apache.org/jira/browse/HADOOP-11182
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 2.5.0, 2.5.1
> Reporter: Sascha Coenen
> Attachments: HADOOP-11182-GraphiteSink-v1.patch, HADOOP-11182-v2.patch
>
>
> the org.apache.hadoop.metrics2.sink.GraphiteSink class emits metrics at the
> configured time period, but the timestamps written only change every 128
> seconds, even it the configured time period in the configuration file is much
> shorter.
> This is due to a bug in line 93:
> {code:java}
> 092 // Round the timestamp to second as Graphite accepts it in
> such format.
> 093 int timestamp = Math.round(record.timestamp() / 1000.0f);
> {code}
> The timestamp property is a long and is divided by a float which yields a
> result that is not precise enough and yields same valued results for
> timestamps that lie up to 128 seconds apart. Also, the result is then written
> into an int variable.
> One solution would be to divide by 1000.0d, but the best fix would be to not
> even convert to a decimal format in the first place. Instead one could
> replace the line with the following:
> {code:java}
> long timestamp = record.timestamp() / 1000L;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
