[
https://issues.apache.org/jira/browse/HDFS-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174366#comment-13174366
]
Uma Maheswara Rao G commented on HDFS-2713:
-------------------------------------------
Thanks a lot, Aaron for taking a look.
{quote}
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.
The current system already supports this. Clients will failover and retry with
some random, exponential backoff for a finite period of time, after which the
operation will fail, throwing an exception.
{quote}
Yes , i agree existing implementation also supports.But the main difference is,
lets take a case with existing implementation, after a finite period of time,
if it is not able to get active node proxy instance it will throw exception and
fail. After some time if other call comes, then again it will do failover. But
with my proposed one, Background thread will continue failover indefinitely
until it finds active proxy instance. So, by the time next call come this
background thread may make ready of active node proxy.
This is the main difference i wanted to explain.
{quote}
The other thing that's not clear to me is how you'd propose to incorporate it
into HDFS. Would it be an alternative to the current implementation? Or done as
an enhancement to the current implementation?
{quote}
here two ways, one way is to enhance the existing
ConfiguredFailOverProxyProvider implementation to incorporate the this
proposal. (separating the failover logic into separate background thread)
Other way is to keep the new proposal as separete FailOverProxyProvider
implementation.
Which one is preferable for you?
> 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
