Return-Path: Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: (qmail 24481 invoked from network); 3 Jun 2010 21:32:19 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 3 Jun 2010 21:32:19 -0000 Received: (qmail 99635 invoked by uid 500); 3 Jun 2010 21:32:18 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 99609 invoked by uid 500); 3 Jun 2010 21:32:18 -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 99601 invoked by uid 99); 3 Jun 2010 21:32:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Jun 2010 21:32:18 +0000 X-ASF-Spam-Status: No, hits=-1495.4 required=10.0 tests=ALL_TRUSTED,AWL X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Jun 2010 21:32:18 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o53LVvnD004723 for ; Thu, 3 Jun 2010 21:31:58 GMT Message-ID: <19248353.167971275600717931.JavaMail.jira@thor> Date: Thu, 3 Jun 2010 17:31:57 -0400 (EDT) From: "sam rash (JIRA)" To: hdfs-issues@hadoop.apache.org Subject: [jira] Commented: (HDFS-1142) Lease recovery doesn't reassign lease when triggered by append() In-Reply-To: <3644025.7991273533151827.JavaMail.jira@thor> 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-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875303#action_12875303 ] sam rash commented on HDFS-1142: -------------------------------- a small sidenote: re: killing writers, it does so *after* getting metadata, so there is still a window under which the client could start another lease recovery, it would complete, and it could start writing and call sync. the 1st lease recovery kills threads, then truncate the block (based on the first set of lengths). This violates sync/hflush semantics. I don't know if there's a jira for this, but I had planned to make the change so the writers *are* killed first thing before getting meta-data. > Lease recovery doesn't reassign lease when triggered by append() > ---------------------------------------------------------------- > > Key: HDFS-1142 > URL: https://issues.apache.org/jira/browse/HDFS-1142 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node > Affects Versions: 0.21.0 > Reporter: Todd Lipcon > Assignee: Todd Lipcon > Attachments: hdfs-1142.txt, hdfs-1142.txt > > > If a soft lease has expired and another writer calls append(), it triggers lease recovery but doesn't reassign the lease to a new owner. Therefore, the old writer can continue to allocate new blocks, try to steal back the lease, etc. This is for the testRecoveryOnBlockBoundary case of HDFS-1139 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.