You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mapreduce-issues@hadoop.apache.org by "Akira AJISAKA (JIRA)" <ji...@apache.org> on 2015/05/18 10:14:00 UTC

[jira] [Commented] (MAPREDUCE-6368) Unreachable Java code

    [ 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.
{code}
    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) {
        ++k;
      }
      writer.append(samples[k], nullValue);
      last = k;
    }
{code}
{{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
(v6.3.4#6332)