Return-Path: Delivered-To: apmail-hadoop-core-dev-archive@www.apache.org Received: (qmail 23037 invoked from network); 19 May 2008 17:36:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 May 2008 17:36:18 -0000 Received: (qmail 47387 invoked by uid 500); 19 May 2008 17:36:17 -0000 Delivered-To: apmail-hadoop-core-dev-archive@hadoop.apache.org Received: (qmail 47364 invoked by uid 500); 19 May 2008 17:36:17 -0000 Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: core-dev@hadoop.apache.org Delivered-To: mailing list core-dev@hadoop.apache.org Received: (qmail 47353 invoked by uid 99); 19 May 2008 17:36:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 May 2008 10:36:17 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 May 2008 17:35:39 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id AA9D7234C118 for ; Mon, 19 May 2008 10:35:55 -0700 (PDT) Message-ID: <833803975.1211218555697.JavaMail.jira@brutus> Date: Mon, 19 May 2008 10:35:55 -0700 (PDT) From: "dhruba borthakur (JIRA)" To: core-dev@hadoop.apache.org Subject: [jira] Commented: (HADOOP-3310) Lease recovery for append In-Reply-To: <70962561.1209080757123.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HADOOP-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598011#action_12598011 ] dhruba borthakur commented on HADOOP-3310: ------------------------------------------ every read request has the blockid and the generation stamp. if the datanode cannot find the block (because the generation stamp has changed), then it will return an exception. The current code also behaves as folows: When a client gets an exception, it retries other replicas. If all these replicas fail, then it goes back to the namenode to re-retrieve block locations. Now, it should get the correct generation stamp of the block. Then, the client will retry the read request to the datanode and this one shud succeed. do you think that this will work? > Lease recovery for append > ------------------------- > > Key: HADOOP-3310 > URL: https://issues.apache.org/jira/browse/HADOOP-3310 > Project: Hadoop Core > Issue Type: New Feature > Components: dfs > Reporter: Tsz Wo (Nicholas), SZE > Assignee: Tsz Wo (Nicholas), SZE > Attachments: 3310_20080514.patch, 3310_20080516b.patch, 3310_20080516c.patch > > > In order to support file append, a GenerationStamp is associated with each block. Lease recovery will be performed when there is a possibility that the replicas of a block in a lease may have different GenerationStamp values. > For more details, see the documentation in HADOOP-1700. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.