hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-13035) Add states INITING and STARTING to YARN Service model to cover in-transition states.
Date Mon, 02 May 2016 10:12:13 GMT

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

Steve Loughran commented on HADOOP-13035:
-----------------------------------------

Thinking about this more, it is possible to make the fact that a service is in a transition
state without changing {{Service.STATE}}, which is the incompatibility barrier.


What is needed is to retain that state model to all existing code, while either making the
state-transition-in-progress condition visible to code
which is aware of the fact that the intermediate states are visible. 

This can be done in a number of ways

h3. a {{transitionInProgress}} variable and accessor

When state is entered, the (atomicBoolean) state is set, cleared on exit. The state of a service
can be queried with something like {{isInState(STATE.STARTED) && !transitionInProgress}}.


Troubespots here are that such a probe is not in itself atomic except if executed in a {{synchronized
block}}, which will also be needed when entering the state. The extra fun happens when stop()
is called during a change, or, say {{start() in init()}}. There are some other corners too:
what if the flag is set, but the service is in state {{NOTINITED}}?

h3. Implement the extended state as a new enum, translate down to the existing state for existing
code in the getters and state probes.


Here there'd be a new interface

{code}

interface ExtendedService extends Service {

enum ExtendedState{ ... = Service.state + transitions}

boolean getExtendedState();

boolean isInExtendedState(ExtendedState es);

boolean canEnterExtendedState(ExtendedState es)

}
{code}

The state model would be the extended one, what would change is the old state queries

{code}
boolean isInState(Service.State s) {
   ExtendedState es = getExtendedState();
   return mapExtendedToSimpleState(es) == s
}

public State mapExtendedToSimpleState(ExtendedState es) {
switch(es) {
  case NOTINITED: return State.NOTINITED;
  case INITED: return State.INITED;
  case INITING: return State.INITED;
  ...
}
 
}

{code}

Actually, you could do the map in the enum itself, with every ExtendedState instance declaring
is simple state in the constructor.


I *believe* this could work, the troublespot would be managing state entry calls, including
{{enterState(State.STARTED)}}, and the addition of child services within a composite service
during the {{serviceInit()}} and {{serviceStart()}} operations.

If this can be shown to implement the extended state model desired and retain backwards compatibility
with subclasses of {{AbstractService}} inside and outside the Hadoop codebase then I'm prepared
to withdraw my -1. I do still require the linked JIRAs to go in first, as they push the boundaries
of the state model further, and, being derivative of the slider workflow services and service
launcher, something we could migrate that code to. That is: if the YARN-679 and YARN-1564
handle this, then testing slider becomes a lot easier.

> Add states INITING and STARTING to YARN Service model to cover in-transition states.
> ------------------------------------------------------------------------------------
>
>                 Key: HADOOP-13035
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13035
>             Project: Hadoop Common
>          Issue Type: Bug
>            Reporter: Bibin A Chundatt
>         Attachments: 0001-HADOOP-13035.patch, 0002-HADOOP-13035.patch, 0003-HADOOP-13035.patch
>
>
> As per the discussion in YARN-3971 the we should be setting the service state to STARTED
only after serviceStart() 
> Currently {{AbstractService#start()}} is set
> {noformat} 
>      if (stateModel.enterState(STATE.STARTED) != STATE.STARTED) {
>         try {
>           startTime = System.currentTimeMillis();
>           serviceStart();
> ..
>  }
> {noformat}
> enterState sets the service state to proposed state. So in {{service.getServiceState}}
in {{serviceStart()}} will return STARTED .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org


Mime
View raw message