Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Thu, 10 May 2012 17:26:57 +0000 (UTC)
From: "Uma Maheswara Rao G (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: 
 <2029889222.50171.1336670817099.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <720031133.38882.1336488348364.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (HDFS-3386) BK JM : Namenode is not deleting his
 lock entry '/ledgers/lock/lock-0000X', when fails to acquire the lock
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Uma Maheswara Rao G updated HDFS-3386:
--------------------------------------

    Issue Type: Sub-task  (was: Bug)
        Parent: HDFS-3399
    
> BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-0000X', when fails to acquire the lock
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-3386
>                 URL: https://issues.apache.org/jira/browse/HDFS-3386
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: ha
>            Reporter: surendra singh lilhore
>            Assignee: Ivan Kelly
>            Priority: Minor
>             Fix For: 2.0.0, 3.0.0
>
>         Attachments: HDFS-3386.diff
>
>
> When a Standby NN becomes Active, it will first create his sequential lock entry create lock-000X  in ZK and then tries to acquire the lock as shown below:
> {quote}
> myznode = zkc.create(lockpath + "/lock-", new byte[] {'0'},
>                                  Ids.OPEN_ACL_UNSAFE,
>                                  CreateMode.EPHEMERAL_SEQUENTIAL);
> if ((lockpath + "/" + nodes.get(0)).equals(myznode)) {
>     if (LOG.isTraceEnabled()) {
>         LOG.trace("Lock acquired - " + myznode);
>     }
>     lockCount.set(1);
>     zkc.exists(myznode, this);
>     return;
>     } else {
>         LOG.error("Failed to acquire lock with " + myznode
>                         + ", " + nodes.get(0) + " already has it");
>         throw new IOException("Could not acquire lock");
>     }  
> {quote}
> Say the transition to standby fails to acquire the lock it will throw the exception and NN is getting shutdown. Here the problem is, the lock entry lock-000X will exists in the ZK till session expiry and the further start-up will not be able to acquire lock.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira