[
https://issues.apache.org/jira/browse/HADOOP-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794063#action_12794063
]
Hemanth Yamijala commented on HADOOP-6439:
------------------------------------------
- In this patch, we are updating a resource in the updatingResource map, if a
null value has been set for a key, but we are not adding the null value to the
properties object storing the key-value mapping. So, suppose a non-null value
is stored for this key from a previously loaded resource, then we would
printing the value belonging to the older resource, but the name of the new
resource. This is inconsistent. In general, I am very skeptical of changing any
behavior in how configurations are loaded because it is so core to the entire
framework. IOW, I would be happy if the old code structure in loadResource is
retained when pulled to the new method loadProperty. Of course, unless there's
a good reason for the change which I'd be happy to see.
- Also, previously whenever we are reloading the properties object, we were
reseting the 'accessed' flag for the deprecated key, which is removed in this
patch.
I haven't looked at the test cases very closely - though the changes seem
mostly OK so far. Cutting down the changes in Configuration.java will actually
allow us to not have to write more test scenarios. So, I would like to relook
at the cases after the changes above are made.
> Shuffle deadlocks on wrong number of maps
> -----------------------------------------
>
> Key: HADOOP-6439
> URL: https://issues.apache.org/jira/browse/HADOOP-6439
> Project: Hadoop Common
> Issue Type: Bug
> Components: conf
> Affects Versions: 0.21.0, 0.22.0
> Reporter: Owen O'Malley
> Assignee: V.V.Chaitanya Krishna
> Priority: Blocker
> Fix For: 0.21.0, 0.22.0
>
> Attachments: HADOOP-6439-1.patch, HADOOP-6439-2.patch,
> HADOOP-6439-3.patch, mr-1252.patch
>
>
> The new shuffle assumes that the number of maps is correct. The new
> JobSubmitter sets the old value. Something misfires in the middle causing:
> 09/12/01 00:00:15 WARN conf.Configuration: mapred.job.split.file is
> deprecated. Instead, use mapreduce.job.splitfile
> 09/12/01 00:00:15 WARN conf.Configuration: mapred.map.tasks is deprecated.
> Instead, use mapreduce.job.maps
> But my reduces got stuck at 2 maps / 12 when there were only 2 maps in the
> job.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
