Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Wed, 18 Dec 2013 16:14:07 +0000 (UTC)
From: "Daryn Sharp (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12685405.1387382238819.58336.1387383247933@arcas>
In-Reply-To: <JIRA.12685405.1387382238819@arcas>
References: <JIRA.12685405.1387382238819@arcas>
Subject: [jira] [Updated] (HDFS-5681) renewLease should not hold fsn write
 lock
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HDFS-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daryn Sharp updated HDFS-5681:
------------------------------

    Attachment: HDFS-5681.patch

I believe the change is truly as simple as changing to a read lock.

The lease manager methods are synchronized and other callers into the lease manager are under the write lock.  My main concern was issues with the lease monitor thread but it too is acquiring the fsn write lock.  There should not be race conditions.

> renewLease should not hold fsn write lock
> -----------------------------------------
>
>                 Key: HDFS-5681
>                 URL: https://issues.apache.org/jira/browse/HDFS-5681
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: namenode
>    Affects Versions: 2.0.0-alpha, 3.0.0
>            Reporter: Daryn Sharp
>         Attachments: HDFS-5681.patch
>
>
> Lease renewals unnecessarily hold the write lock which reduces throughput.  Currently the fsn lock doubles as an "operational lock" to prevent state transitions.  If the lease manager is thread-safe then a read lock is sufficient.


--
This message was sent by Atlassian JIRA
(v6.1.4#6159)