[ 
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)

Reply via email to