hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uma Maheswara Rao G (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-2713) HA : An alternative approach to clients handling Namenode failover.
Date Tue, 24 Jan 2012 09:22:40 GMT

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

Uma Maheswara Rao G commented on HDFS-2713:
-------------------------------------------

Lastly i forgot to mention other point.i.e, We cached the active connection in client in our
internal version. So, that in the same JVM, every new client need not perform failover. First
client will perform failover and others will use the same proxy.
Do you think this will help us to solve below case in this HA proposal( atleast per JVM level)
?
{quote}
>From HA doc section 8.3
o Failover
 time
 is
 longer
 since 
clients 
always 
talks 
to 
the 
first

NN
(who 
may 
be 
dead)
before

looking 
up 
new 
address 
of 
NN.
{quote}

If yes, i will file separate JIRA and start work on that (also this point should not block
initial release).
Am i missing something here?
                
> HA : An alternative approach to clients handling  Namenode failover.
> --------------------------------------------------------------------
>
>                 Key: HDFS-2713
>                 URL: https://issues.apache.org/jira/browse/HDFS-2713
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: ha, hdfs client
>    Affects Versions: HA branch (HDFS-1623)
>            Reporter: Uma Maheswara Rao G
>            Assignee: Uma Maheswara Rao G
>
> This is the approach for client failover which we adopted when we developed HA for Hadoop.
I would like to propose thia approach for others to review & include in the HA implementation,
if found useful.
> This is similar to the ConfiguredProxyProvider in the sense that the it takes the address
of both the Namenodes as the input. The major differences I can see from the current implementation
are
> 1) During failover, user threads can be controlled very accurately about *the time they
wait for active namenode* to be available, awaiting the retry. Beyond this, the threads will
not be made to wait; DFS Client will throw an Exception indicating that the operation has
failed.
> 2) Failover happens in a seperate thread, not in the client application threads. The
thread will keep trying to find the Active Namenode until it succeeds. 
> 3) This also means that irrespective of whether the operation's RetryAction is RETRY_FAILOVER
or FAIL, the user thread can trigger the client's failover. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message