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

Lukas Majercak commented on HDFS-14134:
---------------------------------------

Hi [~John Smith]. I'm not sure if it's that simple.

 Say you have 2 NNs, where nn1 is active, nn2 is standby. If your current 
target is nn2, but we send a request to both, you can get responses like:
nn1 - RETRY
nn2 - RETRY_AND_FAILOVER

In this case, the ideal scenario would be to failover to nn1, but what you're 
proposing would not do that. 

I think this obviously has room for improvement, as in some cases RETRY > 
FAILOVER is reasonable, but I'd like to refrain from increasing the scope of 
this JIRA. Maybe we can create a new one and have the discussion there?

> Idempotent operations throwing RemoteException should not be retried by the 
> client
> ----------------------------------------------------------------------------------
>
>                 Key: HDFS-14134
>                 URL: https://issues.apache.org/jira/browse/HDFS-14134
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: hdfs, hdfs-client, ipc
>            Reporter: Lukas Majercak
>            Assignee: Lukas Majercak
>            Priority: Critical
>         Attachments: HDFS-14134.001.patch, HDFS-14134.002.patch, 
> HDFS-14134.003.patch, HDFS-14134.004.patch, HDFS-14134.005.patch, 
> HDFS-14134.006.patch, HDFS-14134.007.patch, 
> HDFS-14134_retrypolicy_change_proposal.pdf, 
> HDFS-14134_retrypolicy_change_proposal_1.pdf
>
>
> Currently, some operations that throw IOException on the NameNode are 
> evaluated by RetryPolicy as FAILOVER_AND_RETRY, but they should just fail 
> fast.
> For example, when calling getXAttr("user.some_attr", file") where the file 
> does not have the attribute, NN throws an IOException with message "could not 
> find attr". The current client retry policy determines the action for that to 
> be FAILOVER_AND_RETRY. The client then fails over and retries until it 
> reaches the maximum number of retries. Supposedly, the client should be able 
> to tell that this exception is normal and fail fast. 
> Moreover, even if the action was FAIL, the RetryInvocationHandler looks at 
> all the retry actions from all requests, and FAILOVER_AND_RETRY takes 
> precedence over FAIL action.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to