[
https://issues.apache.org/jira/browse/MAPREDUCE-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13543406#comment-13543406
]
Bikas Saha commented on MAPREDUCE-4819:
---------------------------------------
When staging dir exists but commitStarted marker does not exist, then it means
that its a retry that should continue as normal, right?
If yes, shouldnt copyHistory be set to false for the above case? Looks like
copyHistory should be set to true only inside the following block. Only when
commit started, do we need to copy history and end. In other cases, we should
not copy history. Changes initial value of copyHistory to false and set it when
needed?
{code}
+ } else if (commitStarted) {
{code}
Typos "errorHappendShutDown" "NoopEventHanlder"
If we change this code to create new file or fail then AM knows when it has
lost its race to commit. Does this provide a simpler fix for MAPREDUCE-4832?
When AM tries to initiate commit, then only the first one manages to write the
commit_start file in HDFS. So racing AM's will fail after the first one
succeeds. The marker still exists for the purpose of signalling start of commit
(ie for this jira). It should not matter which AM commits the result because
the computation is deterministic. The AM that failed to commit could check/wait
for end of commit marker in order to makes sure that the last retry succeeds
(if that is necessary).
{code}
+ private void touchz(Path p) throws IOException {
+ fs.create(p).close();
+ }
{code}
> AM can rerun job after reporting final job status to the client
> ---------------------------------------------------------------
>
> Key: MAPREDUCE-4819
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-4819
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mr-am
> Affects Versions: 0.23.3, 2.0.1-alpha
> Reporter: Jason Lowe
> Assignee: Bikas Saha
> Priority: Critical
> Attachments: MAPREDUCE-4819.1.patch, MAPREDUCE-4819.2.patch,
> MAPREDUCE-4819.3.patch, MR-4819-bobby-trunk.txt, MR-4819-bobby-trunk.txt,
> MR-4819-bobby-trunk.txt, MR-4819-bobby-trunk.txt, MR-4819-bobby-trunk.txt
>
>
> If the AM reports final job status to the client but then crashes before
> unregistering with the RM then the RM can run another AM attempt. Currently
> AM re-attempts assume that the previous attempts did not reach a final job
> state, and that causes the job to rerun (from scratch, if the output format
> doesn't support recovery).
> Re-running the job when we've already told the client the final status of the
> job is bad for a number of reasons. If the job failed, it's confusing at
> best since the client was already told the job failed but the subsequent
> attempt could succeed. If the job succeeded there could be data loss, as a
> subsequent job launched by the client tries to consume the job's output as
> input just as the re-attempt starts removing output files in preparation for
> the output commit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
