[
https://issues.apache.org/jira/browse/HADOOP-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607547#action_12607547
]
Steve Loughran commented on HADOOP-3628:
----------------------------------------
The interface I've been using in my prototype. Init is for intialisation (and
subclassing), start() starts all worker threads; ping() implements internal
health. terminate() shuts things down. Everything throws exceptions except
terminate(), that is required to do best effort shutdown (catching, logging and
continuing)
public interface HadoopComponentLifecycle {
/**
* Initialize; read in and validate values.
* @throws IOException for any initialisation failure
*/
public void init() throws IOException;
/**
* Start any work (in separate threads)
*
* @throws IOException for any initialisation failure
*/
public void start() throws IOException;
/**
* Ping: only valid when started.
* @throws IOException for any ping failure
*/
void ping() throws IOException;
/**
* Shut down. This must be idempotent and turn errors into log/warn events
-do your best to clean up
* even in the face of adversity.
*/
void terminate();
/**
* Get the current state
* @return the lifecycle state
*/
State getLifecycleState();
/**
* The lifecycle state. Failure is a wierd one as it often takes a side
effecting test (or an oursider) to observe
*/
public enum State {
CREATED,
INITIALIZED,
STARTED,
FAILED,
TERMINATED
}
}
> Add a lifecycle interface for Hadoop components: namenodes, job clients, etc.
> -----------------------------------------------------------------------------
>
> Key: HADOOP-3628
> URL: https://issues.apache.org/jira/browse/HADOOP-3628
> Project: Hadoop Core
> Issue Type: Improvement
> Components: dfs, mapred
> Affects Versions: 0.19.0
> Reporter: Steve Loughran
>
> I'd like to propose we have a standard interface for hadoop components, the
> things that get started or stopped when you bring up a namenode. currently,
> some of these classes have a stop() or shutdown() method, with no standard
> name/interface, but no way of seeing if they are live, checking their health
> of shutting them down reliably. Indeed, there is a tendency for the spawned
> threads to not want to die; to require the entire process to be killed to
> stop the workers.
> Having a standard interface would make it easier for
> * management tools to manage the different things
> * monitoring the state of things
> * subclassing
> The latter is interesting as right now TaskTracker and JobTracker start up
> threads in their constructor; that's very dangerous as subclasses may have
> their methods called before they are full initialised. Adding this interface
> would be the right time to clean up the startup process so that subclassing
> is less risky.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.