[HDFS-135] TestEditLog assumes that FSNamesystem.getFSNamesystem().dir is non-null, even after the FSNameSystem is closed

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Cannot Reproduce
• Assignee: Steve Loughran
• Reporter: Steve Loughran
• Created: 13/Jan/09 14:38
• Updated: 26/Jan/15 22:52
• Resolved: 26/Jan/15 22:52

Description

In my modified services, I'm setting FSNameSystem.dir to null on close():

        if(dir != null) {
         dir.close();
         dir =  null;
        }

This breaks TestEditLog

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)

There are two possible conclusions here.

1. Setting dir=null in FSNameSystem.close() is a regression and should be fixed
2. 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

Issue Links

• is related to: HADOOP-5037 Deprecate FSNamesystem.getFSNamesystem() and change fsNamesystemObject to private