hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlos Valiente (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HADOOP-5257) Export namenode/datanode functionality through a pluggable RPC layer
Date Mon, 16 Mar 2009 20:29:50 GMT

     [ https://issues.apache.org/jira/browse/HADOOP-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Carlos Valiente updated HADOOP-5257:
------------------------------------

    Attachment: HADOOP-5257-v4.patch

Thanks for your feedback, Konstantin

bq. 1. DFS should be HDFS

Yep - done in HADOOP-5257-v4.patch

bq. 2. It is not clear from the name TestGetInstances what it tests and there is no JavaDoc
explaining it.

I've added a javadoc comment explaining the purpose of the test.

bq. 3. It would be better if classes ChildInterface, SampleInterface, AnotherClass, SampleClass
were static subclasses of TestGetInstances.

Done.

While modifying the javadoc for {{org.apache.hadoop.hdfs.server.protocol.Plugin}}, I've noticed
there's nothing HDFS-specific to that interface - should it perhaps be moved to some place
under {{src/core}} instead?

> Export namenode/datanode functionality through a pluggable RPC layer
> --------------------------------------------------------------------
>
>                 Key: HADOOP-5257
>                 URL: https://issues.apache.org/jira/browse/HADOOP-5257
>             Project: Hadoop Core
>          Issue Type: New Feature
>          Components: dfs
>            Reporter: Carlos Valiente
>            Priority: Minor
>         Attachments: HADOOP-5257-v2.patch, HADOOP-5257-v3.patch, HADOOP-5257-v4.patch,
HADOOP-5257-v4.patch, HADOOP-5257.patch
>
>
> Adding support for pluggable components would allow exporting DFS functionallity using
arbitrary protocols, like Thirft or Protocol Buffers. I'm opening this issue on Dhruba's suggestion
in HADOOP-4707.
> Plug-in implementations would extend this base class:
> {code}abstract class Plugin {
>     public abstract datanodeStarted(DataNode datanode);
>     public abstract datanodeStopping();
>     public abstract namenodeStarted(NameNode namenode);
>     public abstract namenodeStopping();
> }{code}
> Name node instances would then start the plug-ins according to a configuration object,
and would also shut them down when the node goes down:
> {code}public class NameNode {
>     // [..]
>     private void initialize(Configuration conf)
>         // [...]
>         for (Plugin p: PluginManager.loadPlugins(conf))
>           p.namenodeStarted(this);
>     }
>     // [..]
>     public void stop() {
>         if (stopRequested)
>             return;
>         stopRequested = true;
>         for (Plugin p: plugins) 
>             p.namenodeStopping();
>         // [..]
>     }
>     // [..]
> }{code}
> Data nodes would do a similar thing in {{DataNode.startDatanode()}} and {{DataNode.shutdown}}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message