If it really is the ordering of the hash map I would say no it should not, and the code should be updated. If ordering matters we need to use a map that guarantees a given order, and hash map is not one of them.
--Bobby Evans On 3/22/12 7:24 AM, "Kumar Ravi" <gokumarr...@gmail.com> wrote: Hello, We have been looking at IBM JDK junit failures on Hadoop-1.0.1 independently and have ran into the same failures as reported in this JIRA. I have a question based upon what I have observed below. We started debugging the problems in the testcase - org.apache.hadoop.mapred.lib.TestCombineFileInputFormat The testcase fails because the number of splits returned back from CombineFileInputFormat.getSplits() is 1 when using IBM JDK whereas the expected return value is 2. So far, we have found the reason for this difference in number of splits is because the order in which elements in the rackToBlocks hashmap get created is in the reverse order that Sun JDK creates. The question I have at this point is -- Should there be a strict dependency in the order in which the rackToBlocks hashmap gets populated, to determine the number of splits that get should get created in a hadoop cluster? Is this Working as designed? Regards, Kumar
