Return-Path: X-Original-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1A9C61646C for ; Fri, 21 Nov 2014 19:51:34 +0000 (UTC) Received: (qmail 3180 invoked by uid 500); 21 Nov 2014 19:51:33 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 3125 invoked by uid 500); 21 Nov 2014 19:51:33 -0000 Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-issues@hadoop.apache.org Delivered-To: mailing list hdfs-issues@hadoop.apache.org Received: (qmail 3113 invoked by uid 99); 21 Nov 2014 19:51:33 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Nov 2014 19:51:33 +0000 Date: Fri, 21 Nov 2014 19:51:33 +0000 (UTC) From: "Jing Zhao (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HDFS-7412) Move RetryCache to NameNodeRpcServer MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HDFS-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14221340#comment-14221340 ] Jing Zhao commented on HDFS-7412: --------------------------------- Looks like in our current implementation we have two patterns: 1) doing OperationCategory check before retry cache check, or 2) checking retry cache before the OperationCategory check. The difference here is that for 1) if the client side's retry happens during the NN failover, the client has to failover to the other NN to get the result stored in retry cache, which may cause issue if the client has already hit the max failover times. The current patch makes sure all the calls follow pattern 2), which should be a good change. After the change the FSNamesystem calls have to take an extra argument to indicate whether the retry cache is available. Since this is only used to determine whether to record call/client id in the edits, maybe we can let fseditlog check a globally visible marker or even a threadlocal context, so that we can hide this logic away from the FSNamesystem APIs. But this can be future work addressed by a separate jira. > Move RetryCache to NameNodeRpcServer > ------------------------------------ > > Key: HDFS-7412 > URL: https://issues.apache.org/jira/browse/HDFS-7412 > Project: Hadoop HDFS > Issue Type: Sub-task > Reporter: Haohui Mai > Assignee: Haohui Mai > Attachments: HDFS-7412.000.patch > > > The concept of RetryCache belongs to the RPC layer.It would be nice to separate it from the implementation of {{FSNameSystem}}. -- This message was sent by Atlassian JIRA (v6.3.4#6332)