[
https://issues.apache.org/jira/browse/HADOOP-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594947#action_12594947
]
Steve Loughran commented on HADOOP-3360:
----------------------------------------
Having done a bit more coding, its worth noting I've just done what I shouldnt
-subclassed DataNode and NameNode in the org.apache.hadoop.dfs package itself,
in order to
-get at the package scoped constructor of DataNode
-get at some internal package-scoped fields
-add the synchronisation I want around shutdown
-run DataNode in my own thread
-add the ability to ping() either node type and check their health. For
NameNode, that means getting at the filesystem and checking it is running, for
a datanode, the only check I can patch in is that the worker thread is running.
This is all pretty nasty stuff, and does need fixing...this bug lays down what
is wrong. What I don't yet know is what is the right thing to do. Give me a few
more weeks to experiment, then I will probably propose something like
-a base lifecycle interface for server-side nodes that includes start(),stop()
and ping() methods
-a base thread class that catches and caches exceptions thrown during their
operation
-retrofit of this into NameNode,DataNode and others.
> DataNode should be marked as final to prevent subclassing
> ---------------------------------------------------------
>
> Key: HADOOP-3360
> URL: https://issues.apache.org/jira/browse/HADOOP-3360
> Project: Hadoop Core
> Issue Type: Bug
> Components: dfs
> Affects Versions: 0.16.3
> Reporter: Steve Loughran
> Priority: Minor
>
> Reviewing the DataNode core, it starts a thread in its constructor calling
> back in to the Run() method. This is generally perceived as very dangerous,
> as if DataNode were ever subclassed, the subclass would start to be invoked
> in the run() method before its own constructor had finished working.
> 1. Consider splitting the constructor from the start() operation.
> 2. If this cannot be changed, mark DataNode as final so nobody can subclass
> it. Though if the latter were done, it would be convenient to have a method
> to let external management components poll for the health of the node, and to
> pick up reasons for the node shutting down.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
