[
https://issues.apache.org/jira/browse/HADOOP-11182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169378#comment-14169378
]
Sascha Coenen commented on HADOOP-11182:
----------------------------------------
Thanks Ravi for pointing me to the repository to use.
I resubmitted another path against the trunk of the git repo this time.
Also added a new unit test class as the GraphiteSink class didn't have a unit
test class yet.
Added one test which fails if the fix is not applied but succeeds under the fix.
I was not able to go through with all "HowToContribute" suggestions though.
Some strange things happened on my system like timeouts during test executions.
However, these failures seem to be unrelated to my patch. I also get a "The
patch does not appear to apply with p0 to p2" from the dev-support script. No
idea what this is supposed to mean, nor do I find anything on googling for that
message.
I hope that this patch will do. I've spent about a day on it. If the patch
still does not go through, it would be nice if someone more familiar with the
workflow could make the modification on my behalf as it is just a single line
of code that needs to be replaced in the code.
Thanks
> 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)
