You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Steve Loughran (JIRA)" <ji...@apache.org> on 2009/01/13 15:39:09 UTC
[jira] Assigned: (HADOOP-5021) TestEditLog assumes that
FSNamesystem.getFSNamesystem().dir is non-null, even after the FSNameSystem
is closed
[ https://issues.apache.org/jira/browse/HADOOP-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steve Loughran reassigned HADOOP-5021:
--------------------------------------
Assignee: Steve Loughran
> TestEditLog assumes that FSNamesystem.getFSNamesystem().dir is non-null, even after the FSNameSystem is closed
> --------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-5021
> URL: https://issues.apache.org/jira/browse/HADOOP-5021
> Project: Hadoop Core
> Issue Type: Bug
> Components: dfs
> Affects Versions: 0.21.0
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.