hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HDFS-135) TestEditLog assumes that FSNamesystem.getFSNamesystem().dir is non-null, even after the FSNameSystem is closed
Date Mon, 26 Jan 2015 22:52:35 GMT

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

Steve Loughran resolved HDFS-135.
---------------------------------
    Resolution: Cannot Reproduce

> TestEditLog assumes that FSNamesystem.getFSNamesystem().dir is non-null, even after the
FSNameSystem is closed
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-135
>                 URL: https://issues.apache.org/jira/browse/HDFS-135
>             Project: Hadoop HDFS
>          Issue Type: Bug
>            Reporter: Steve Loughran
>            Assignee: Steve Loughran
>
> In my modified services, I'm setting {{FSNameSystem.dir}} to {{null}} on {{close()}}:
> {code}
>         if(dir != null) {
>          dir.close();
>          dir =  null;
>         }
> {code}
> This breaks TestEditLog
> {code}
> java.lang.NullPointerException
> at org.apache.hadoop.hdfs.server.namenode.FSEditLog.loadFSEdits(FSEditLog.java:620)
> at org.apache.hadoop.hdfs.server.namenode.TestEditLog.testEditLog(TestEditLog.java:148)
> {code}
> There are two possible conclusions here. 
> # Setting dir=null in {{FSNameSystem.close()}} is a regression and should be fixed
> # The test contains some assumptions that are not valid
> I will leave it to others to decide; I will try and fix the code whichever approach is
chosen. Personally, I'd go for setting dir=null as it is cleaner, but there is clearly some
risk of backward's compatibility problems, at least in test code



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message