hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harsh J Chouraria (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MAPREDUCE-2384) Can MR make error response Immediately?
Date Sun, 08 May 2011 11:09:03 GMT

    [ https://issues.apache.org/jira/browse/MAPREDUCE-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030471#comment-13030471
] 

Harsh J Chouraria commented on MAPREDUCE-2384:
----------------------------------------------

1. is an easy one to fix (basically to move job spec check a step up). I have a patch for
this in pipeline.

2. as per OP, is to not build JIP until after the config checks. I think it is alright to
have it the way it is now, since to check pre-JIP construct would still require one extra
lookup to occur (the config props that are to be checked, are also used elsewhere later).
Besides, its easier to read/maintain with the JIP methods and I don't think the construction
time (a few property loads, some array decls) would take much time.

What are your thoughts on 2.; would we benefit enough to refactor the parts to not use JIP
(and construct it only after validity is verified)?

> Can MR make error response Immediately?
> ---------------------------------------
>
>                 Key: MAPREDUCE-2384
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-2384
>             Project: Hadoop Map/Reduce
>          Issue Type: Improvement
>          Components: job submission
>    Affects Versions: 0.21.0
>            Reporter: Denny Ye
>            Assignee: Harsh J Chouraria
>
> When I read the source code of MapReduce in Hadoop 0.21.0, sometimes it made me confused
about error response. For example:
>         1. JobSubmitter checking output for each job. MapReduce makes rule to limit that
each job output must be not exist to avoid fault overwrite. In my opinion, MR should verify
output at the point of client submitting. Actually, it copies related files to specified target
and then, doing the verifying. 
>         2. JobTracker.   Job has been submitted to JobTracker. In first step, JT create
JIT object that is very "huge" . Next step, JT start to verify job queue authority and memory
requirements.
>  
>         In normal case, verifying client input then response immediately if any cases
in fault. Regular logic can be performed if all the inputs have passed.  
>         It seems like that those code does not make sense for understanding. Is only
my personal opinion? Wish someone help me to explain the details. Thanks!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message