hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tsz Wo Nicholas Sze (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-7926) NameNode implementation of ClientProtocol.truncate(..) is not idempotent
Date Sat, 14 Mar 2015 01:44:38 GMT

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

Tsz Wo Nicholas Sze commented on HDFS-7926:

"idempotent" means applying the same operations multiple times will get the same result. 
If there is an append in the middle, the retry could get different results.

E.g. getPermission is idempotent.  However, if there is a setPermission (or delete, rename,
etc.) in the middle, the retry of getPermission could get a different result.

> NameNode implementation of ClientProtocol.truncate(..) is not idempotent
> ------------------------------------------------------------------------
>                 Key: HDFS-7926
>                 URL: https://issues.apache.org/jira/browse/HDFS-7926
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: namenode
>            Reporter: Tsz Wo Nicholas Sze
>            Assignee: Tsz Wo Nicholas Sze
>             Fix For: 2.7.0
>         Attachments: h7926_20150313.patch, h7926_20150313b.patch
> If dfsclient drops the first response of a truncate RPC call, the retry by retry cache
will fail with "DFSClient ... is already the current lease holder".  The truncate RPC is annotated
as @Idempotent in ClientProtocol but the NameNode implementation is not.

This message was sent by Atlassian JIRA

View raw message