hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Akira AJISAKA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MAPREDUCE-6368) Unreachable Java code
Date Mon, 18 May 2015 08:14:00 GMT

    [ https://issues.apache.org/jira/browse/MAPREDUCE-6368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14547690#comment-14547690

Akira AJISAKA commented on MAPREDUCE-6368:

Thanks [~dhirajnilange] for reporting this issue. I'm thinking the condition can be true.
    float stepSize = samples.length / (float) numPartitions;
    int last = -1;
    for(int i = 1; i < numPartitions; ++i) {
      int k = Math.round(stepSize * i);
      while (last >= k && comparator.compare(samples[last], samples[k]) == 0) {
      writer.append(samples[k], nullValue);
      last = k;
{{k = Math.round(stepSize * i)}} can be equal to {{last = Math.round(stepSize * (i-1))}} if
{{stepSize}} is less than 1.

> Unreachable Java code
> ---------------------
>                 Key: MAPREDUCE-6368
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6368
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: mrv2
>    Affects Versions: 2.6.0
>            Reporter: Dhiraj Nilange
>            Priority: Minor
> Reference
> Class: org.apache.hadoop.mapreduce.lib.partition.InputSampler
> Method: writePartitionFile
> Line: 337
> The issue exists in the following code loop at line 337:-
> while (last >= k && comparator.compare(samples[last], samples[k]) == 0) 
> {
>       ++k; 
>  }
> The problem is that the first condition in the while loop (last >= k) will always
be false. The value of 'last' will always be lesser than 'k' and hence the first condition
will never evaluate to true. There is second condition as well but since it is appearing as
AND condition, that will never be checked since the first condition itself is false. Hence
this loop is not contributing towards the code output anyways. If this was intended to execute,
then I guess it will need investigation. But from what I have noticed, it doesn't seem to
harm the output of the method. In that case why even keep it there. We could very well remove
it from the code. And if this was done with the some other intention, in that case this needs
to be corrected as currently it is unreachable code. This issue very much exists in the release
2.6.0, I have not seen the release 2.7.0 source code, but it may very well exist in that as
well (it's worth checking).
> Thanks & Regards,
> Dhiraj

This message was sent by Atlassian JIRA

View raw message