You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mapreduce-issues@hadoop.apache.org by "Siddharth Seth (JIRA)" <ji...@apache.org> on 2012/09/13 21:16:08 UTC

[jira] [Commented] (MAPREDUCE-4596) Split StateMachine state from states seen by MRClientProtocol (for Job, Task, TaskAttempt)

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

Siddharth Seth commented on MAPREDUCE-4596:
-------------------------------------------

Thanks for the review.

bq. How about JobStateInternal, TaskStateInternal and TaskAttemptInternal?
Yep. The current names are terrible. Was trying to keep them short considering their extensive use in state machine definition.

bq. Also, Job,Task and TaskAttempt (internal) interfaces don't need to expose the (external) JobState/TaskState etc.
Unfortunately, the history server is tied to these interfaces. Not exposing the external state, would mean the history server may not be usable across minor AM changes.
Eventually, we could change the history server to rely on hadoop-mapreduce-client-api - instead of a specific app, and ensure that no other module depends on the Job,Task,TaskAttempt interfaces. For now though, I think we need to keep the external getState(). Will try getting rid of the internal getState() though - since that should not be used anywhere outside of the hadoop-mapreduce-client-app module.

bq. Interesting question is about the 0.23 releases and their compatibility 
I don't see the point of retaining proto field numbers if this will change. The options I see are 
1) Don't change the hadoop-mapreduce-client-api states. Would allow a .23 client to talk to a 2.0 AM.
2) Define states in hadoop-mapreduce-client-api which are useful to the client. 0.23 clients may fail when talking to 2.0 AMs. I'd prefer this option - since I don't think the APIs are finalized yet, MRv1 APIs are being touched, and there's several states like KILL_CONTAINER_CLEANUP, KILL_TASK_CLEANUP - which don't make a lot of sense for clients.
                
> Split StateMachine state from states seen by MRClientProtocol (for Job, Task, TaskAttempt)
> ------------------------------------------------------------------------------------------
>
>                 Key: MAPREDUCE-4596
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-4596
>             Project: Hadoop Map/Reduce
>          Issue Type: Task
>          Components: applicationmaster, mrv2
>    Affects Versions: 0.23.0
>            Reporter: Siddharth Seth
>            Assignee: Siddharth Seth
>         Attachments: MR4596.txt
>
>
> State machine states are currently exposed via MRClienProtocol. This makes it tough to modify the AM state machines, or have an alternate AM with different state machines (MR-3902) without the changes being visible in MRClientProtocol (MRv2 equivalent of ClientProtocol).

--
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