[
https://issues.apache.org/jira/browse/MAPREDUCE-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514989#comment-14514989
]
Vinod Kumar Vavilapalli commented on MAPREDUCE-6251:
----------------------------------------------------
bq. Those are all calls that happen on the job we are adding retries for here,
so they are getting the benefit of the retry. In fact, anything of this sort
looks to go through this getJob bit, so it is such a center point
That's good to know. We should definitely rename the configuration properties
then. The default retry should also be such that there is no retry - users can
explicitly override if they want in the context of specific FileSystems.
bq. I don't believe so - callers are expecting to get a response for valid
queries ...
I guess a different problem I have is that the retry is always happening,
whether going to the history-server or to the AM. Given the problem is only in
the context of JobHistoryServer, should it be localized to calls to the
HistoryServer?
> JobClient needs additional retries at a higher level to address
> not-immediately-consistent dfs corner cases
> -----------------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-6251
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6251
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: jobhistoryserver, mrv2
> Affects Versions: 2.6.0
> Reporter: Craig Welch
> Assignee: Craig Welch
> Attachments: MAPREDUCE-6251.0.patch, MAPREDUCE-6251.1.patch,
> MAPREDUCE-6251.2.patch
>
>
> The JobClient is used to get job status information for running and completed
> jobs. Final state and history for a job is communicated from the application
> master to the job history server via a distributed file system - where the
> history is uploaded by the application master to the dfs and then
> scanned/loaded by the jobhistory server. While HDFS has strong consistency
> guarantees not all Hadoop DFS's do. When used in conjunction with a
> distributed file system which does not have this guarantee there will be
> cases where the history server may not see an uploaded file, resulting in the
> dreaded "no such job" and a null value for the RunningJob in the client.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
