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

Vinod Kumar Vavilapalli commented on MAPREDUCE-3098:
----------------------------------------------------

bq. True however what this actually represents is the state of the current 
attempt's AM.
That's not true and which I am trying to impress upon. ApplicationState.New and 
ApplicationState.SUBMITTED don't even represent any state of the AM. 
ApplicationState.RUNNING means multiple things: it may be that an AM is 
running, or it may also mean that AM is down and in the process of restarting. 
ApplicationState.FAILED may actually mean that the platform is not even able to 
launch the AM for some reason.

To be semantically correct, RMAppAttemptState represents the AM state, 
ApplicationState is much more than RMAppAttemptState, it subsumes the whole 
application including any and all app-attempts.

bq. A submitted/running/completed AM only really implies the state of the AM 
and it would be better if we changed this from ApplicationState to 
ApplicationMasterState to avoid confusion as to what it really implies.
Ditto. Like I pointed above, ApplicationState.Running doesn't map directly to a 
running AM, neither does ApplicationState.FAILED represent actual job-failure.

bq. From the perspective of a client, a client would prefer to assume that the 
application 'finish' state is whether my "job" completed successfully or not.
Not sure if you worked with other resource-managers which give you an ability 
to run your own code. In torque, for example, the corresponding state for 
ApplicationState.FINISHED only means the app has finished. To know what 
happened to your actual job, you need a separate state.

bq. The RM does not need to act on it today so a string should work. However, 
the question is whether using a flexible string/blob based approach is the way 
to go? I, in particular, do not have any preference over string/enum.
I prefer the blob approach as having an enum is stricter and obviously we 
cannot have an enum representing final-states for all possible frameworks.

bq. A client would monitoring AppMasterState for completion ( 
succeeded/failed/killed ) and if succeeded, look at the ApplicationFinishState 
to actually verify that the work was done successfully.
Given above, a client would be instead monitoring for ApplicationState, if it 
is one of the final states SUCCEEDED, FAILED or KILLED, it will look at the 
corresponding ApplicationReport.FinalFrameworkState to see what actually 
happened to the job.

Apologies if I am giving an impression of creating a storm. But honestly all of 
this was thought through earlier end-to-end and I firmly belive that the 
current states and records represent the correct abstraction.
                
> Report Application status as well as ApplicationMaster status in 
> GetApplicationReportResponse 
> ----------------------------------------------------------------------------------------------
>
>                 Key: MAPREDUCE-3098
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-3098
>             Project: Hadoop Map/Reduce
>          Issue Type: Sub-task
>          Components: mrv2
>    Affects Versions: 0.23.0
>            Reporter: Hitesh Shah
>            Assignee: Hitesh Shah
>            Priority: Blocker
>             Fix For: 0.23.0
>
>
> Currently, an application report received by the client from the RM/ASM for a 
> given application returns the status of the application master. It does not 
> return the status of the application i.e. whether that particular job 
> succeeded or failed. 
> The AM status would be one of FINISHED (SUCCEEDED should be renamed to 
> FINISHED as AM state does not indicate overall success/failure), FAILED or 
> KILLED. 
> The final state sent by the AM to the RM in the 
> FinishApplicationMasterRequest should be exposed to the client as 
> ApplicationState. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to