Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Mon, 8 Aug 2011 19:40:27 +0000 (UTC)
From: "Aaron T. Myers (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: 
 <1532157034.17551.1312832427142.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <186832252.30971.1305909407515.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HDFS-1974) HA: Introduce active and standby
 states to the namenode
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HDFS-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081152#comment-13081152 ] 

Aaron T. Myers commented on HDFS-1974:
--------------------------------------

Thanks for posting this design doc, Suresh. Some comments on the latest patch:

# {{public static boolean isHAEnabled(Configuration conf)}} - is the intention that this will return true if HA is enabled on the cluster? Or that this will return true only on the currently-active NN? The answer to this question may invalidate the next question.
# {{this.state = DFSUtil.isHAEnabled(conf) ? ACTIVE_STATE : STANDBY_STATE;}} - should probably be replaced with a TODO. It's obviously not reasonable to have both NNs start as active just because HA is enabled. There needs to be some leader determination.
# In {{HAState}}, why not make {{enterState}} and {{exitState}} abstract?
# I find it unfortunate/brittle that every FS operation call in {{NameNode}} now has to include the method name as a string, particularly since this is only used for logging. Is the stack trace, which will include the method name, not sufficient?
# {{UnsupportedActionException}} seems redundant with {{o.a.h.ipc.StandbyException}}.
# In {{NameNode.OperationCategory}}, the comments are identical for {{CHECKPOINT}} and {{JOURNAL}} operations. For that matter, I'm not sure which operations are intended to fall under {{JOURNAL}}.
# {{StandbyState.checkOperation}} for the time being, it doesn't make sense that we should be serving reads from the standby. We don't yet have any guarantees about the freshness of the standby's date. Let's leave that for a later optimization.
# I don't understand the purpose of having both {{HAState.setState}} and {{HAState.(standbyToActive|activeToStandby)}}. Shouldn't just {{setState}} be sufficient?
# In {{HAState.setState}}, you have {{exitState(nn); s.enterState(nn);}}. What state should the NN be considered to be in between these calls?
# You never reassign the value of {{NameNode.state}}.
# There's no synchronization in this patch. Many or most of these operations will need some locking.
# It seems like all of the new classes should go in the {{o.a.h.hdfs.server.namenode.ha}} package, rather than just {{o.a.h.hdfs.server.namenode}}.

> HA: Introduce active and standby states to the namenode
> -------------------------------------------------------
>
>                 Key: HDFS-1974
>                 URL: https://issues.apache.org/jira/browse/HDFS-1974
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: name-node
>            Reporter: Suresh Srinivas
>            Assignee: Suresh Srinivas
>         Attachments: HDFS-1974.1.patch, HDFS-1974.2.patch, HDFS-1974.patch
>
>
> Currently namenode supports active, secondary and backup roles. To support namenode high availability, active and standby states are needed. Note that this is different from the existing notion of namenode role, where a namenode cannot transition from one role to the other.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira