hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-5385) Caching RPCs are AtMostOnce, but do not persist client ID and call ID to edit log.
Date Mon, 21 Oct 2013 19:51:43 GMT

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

Chris Nauroth commented on HDFS-5385:
-------------------------------------

Thanks!

[~cmccabe] and [~andrew.wang], you probably noticed this in the code review, but I wanted
to call out that this change is backwards-incompatible with any edit logs that you might have
in your HDFS-4949 testing clusters.  This backwards-incompatibility is exactly why I wanted
to get this patch done as a pre-requisite for the trunk merge, so that others won't have to
go through the churn.

> Caching RPCs are AtMostOnce, but do not persist client ID and call ID to edit log.
> ----------------------------------------------------------------------------------
>
>                 Key: HDFS-5385
>                 URL: https://issues.apache.org/jira/browse/HDFS-5385
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: namenode
>    Affects Versions: HDFS-4949
>            Reporter: Chris Nauroth
>            Assignee: Chris Nauroth
>             Fix For: HDFS-4949
>
>         Attachments: HDFS-5385.1.patch
>
>
> All of the new caching RPCs defined on {{ClientProtocol}} are annotated {{@AtMostOnce}}.
 However, their underlying edit log operations do not persist the RPC client ID and call ID.
 In the event of an HA failover, the new primary will not be able to guarantee at-most-once
semantics if the clients retry.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message