[
https://issues.apache.org/jira/browse/HADOOP-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Loughran updated HADOOP-3628:
-----------------------------------
Attachment: hadoop-3628.patch
This patch is creates an abstract base class Service (in util) with a
lifecycle, retrofits to NameNode, DataNode, JobTracker and makes the changes to
MiniDFS needed to get all the tests to work (at least here). It is up to date
with movements of the dfs code. which is why I'm submitting today and not last
friday.
-it also adds a standalone test that MiniDFS works. MiniDFS could be enhanced
to share the same base class lifecycle; this could be done while improving its
startup/shutdown times, which is the main reason the test cycle for hadoop is
so long.
-it doesn't make any major attempts to fix problems with startup/shutdown of
services that have been noted in filed bugreps, except that service termination
is now synchronized. Once the patch is in other lifecycle issues with the nodes
can be looked at.
> 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
> Assignee: Steve Loughran
> Attachments: AbstractHadoopComponent.java, hadoop-3628.patch
>
>
> 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.
