hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-2385) Validate configuration parameters
Date Wed, 09 Jan 2008 20:57:34 GMT

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

Doug Cutting commented on HADOOP-2385:
--------------------------------------

> Why setters need to be static?

Users need to, e.g., be able to set HDFS parameters on a JobConf.  We can get away with a
single subclass of Configuration that has setters, but once we add a second, it would be impossible
to create a single configuration instance that can configure multiple components.

> Why per-package, not per-component?

That's fine too.  You seemed to be complaining that classes were too specific for this case,
so I said I was okay with per-package if you thought that more appropirate here, although
perhaps that's too general for your taste in this case, and you'd rather separate, e.g., Namenode
from Datanode parameters.  That's fine with me too.  However I don't find the argument that
FSNamesystem is already too big compelling.  That's a separate issue: it should perhaps be
decomposed into multiple classes, and when that's done, configuration accessors might move
around, but if there are FSNamesystem-specific configuration accessors then I'd argue they
belong in FSNamesystem, regardless of that class's current size.

> Validate configuration parameters
> ---------------------------------
>
>                 Key: HADOOP-2385
>                 URL: https://issues.apache.org/jira/browse/HADOOP-2385
>             Project: Hadoop
>          Issue Type: Improvement
>          Components: dfs
>    Affects Versions: 0.16.0
>            Reporter: Robert Chansler
>
> Configuration parameters should be fully validated before name nodes or data nodes begin
service.
> Required parameters must be present.
> Required and optional parameters must have values of proper type and range.
> Undefined parameters must not be present.
> (I was recently observing some confusion whose root cause was a mis-spelled parameter.)

-- 
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