hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HDFS-2877) If locking of a storage dir fails, it will remove the other NN's lock file on exit
Date Thu, 02 Feb 2012 22:14:53 GMT

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

Todd Lipcon updated HDFS-2877:
------------------------------

          Resolution: Fixed
       Fix Version/s: 0.22.1
                      1.1.0
                      0.23.1
                      0.24.0
    Target Version/s: 0.23.1, 1.1.0, 0.22.1  (was: 0.22.1, 1.1.0, 0.23.1)
        Hadoop Flags: Reviewed
              Status: Resolved  (was: Patch Available)

Verified that the above situation is true by starting a NN, kill -9ing it, and starting it
again. It properly comes up and acquires the lock. On a graceful shutdown it removes the lock.

Committed to trunk, 22, 23, and 1.1. Thanks for the reviews.
                
> If locking of a storage dir fails, it will remove the other NN's lock file on exit
> ----------------------------------------------------------------------------------
>
>                 Key: HDFS-2877
>                 URL: https://issues.apache.org/jira/browse/HDFS-2877
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: name-node
>    Affects Versions: 0.23.0, 0.24.0, 1.0.0
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>             Fix For: 0.24.0, 0.23.1, 1.1.0, 0.22.1
>
>         Attachments: hdfs-2877.txt
>
>
> In {{Storage.tryLock()}}, we call {{lockF.deleteOnExit()}} regardless of whether we successfully
lock the directory. So, if another NN has the directory locked, then we'll fail to lock it
the first time we start another NN. But our failed start attempt will still remove the other
NN's lockfile, and a second attempt will erroneously start.

--
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

        

Mime
View raw message