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

Kitti Nanasi commented on HDFS-14134:
-------------------------------------

[~lukmajercak], you are correct on the definition of idempotency. I think the 
original approach in retrying was that idempotent operations don't change 
internal state, so it is safe to retry them. For example if you just get a 
value, it is always safe to retry, but if you renew a delegation token, it is a 
more complex question if it is safe to retry that or not, because maybe the 
renewal already took place before failing, maybe not, and if it already took 
place, is it safe to renew it again?

 

By the way idempotency originally was only considered in case of non-remote 
IOExceptions, why did that change?

> 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_retrypolicy_change_proposal.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: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org

Reply via email to