hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jitendra Nath Pandey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-7926) NameNode implementation of ClientProtocol.truncate(..) is not idempotent
Date Fri, 13 Mar 2015 05:34:38 GMT

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

Jitendra Nath Pandey commented on HDFS-7926:
--------------------------------------------

[~szetszwo], I think the patch works correctly and returns false if the truncate is called
the second time. But for a file being written or appended, truncate will still return false
if the oldlength happens to be same as newlength. It should throw an exception in this scenario.
In this approach, it seems there is a need to distinguish whether file is under construction
due to a truncate or due to a create/append.

> 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
>         Attachments: h7926_20150313.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
(v6.3.4#6332)

Mime
View raw message