Uploaded image for project: 'Hadoop HDFS'
  1. Hadoop HDFS
  2. HDFS-7385

ThreadLocal used in FSEditLog class causes FSImage permission mess up

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.4.0, 2.5.0
    • Fix Version/s: 2.6.0
    • Component/s: namenode
    • Labels:
      None
    • Target Version/s:
    • Hadoop Flags:
      Reviewed

      Description

      We migrated our NameNodes from low configuration to high configuration machines last week. Firstly,we imported the current directory including fsimage and editlog files from original ActiveNameNode to new ActiveNameNode and started the New NameNode, then changed the configuration of all datanodes and restarted all of datanodes , then blockreport to new NameNodes at once and send heartbeat after that.
      Everything seemed perfect, but after we restarted Resoucemanager , most of the users compained that their jobs couldn't be executed for the reason of permission problem.
      We applied Acls in our clusters, and after migrated we found most of the directories and files which were not set Acls before now had the properties of Acls. That is the reason why users could not execute their jobs.So we had to change most of the files permission to a+r and directories permission to a+rx to make sure the jobs can be executed.
      After searching this problem for some days, i found there is a bug in FSEditLog.java. The ThreadLocal variable cache in FSEditLog don’t set the proper value in logMkdir and logOpenFile functions. Here is the code of logMkdir:
      public void logMkDir(String path, INode newNode) {
      PermissionStatus permissions = newNode.getPermissionStatus();
      MkdirOp op = MkdirOp.getInstance(cache.get())
      .setInodeId(newNode.getId())
      .setPath(path)
      .setTimestamp(newNode.getModificationTime())
      .setPermissionStatus(permissions);

      AclFeature f = newNode.getAclFeature();
      if (f != null)

      { op.setAclEntries(AclStorage.readINodeLogicalAcl(newNode)); }

      logEdit(op);
      }
      For example, if we mkdir with Acls through one handler(Thread indeed), we set the AclEntries to the op from the cache. After that, if we mkdir without any Acls setting and set through the same handler, the AclEnties from the cache is the same with the last one which set the Acls, and because the newNode have no AclFeature, we don’t have any chance to change it. Then the editlog is wrong,record the wrong Acls. After the Standby load the editlogs from journalnodes and apply them to memory in SNN then savenamespace and transfer the wrong fsimage to ANN, all the fsimages get wrong. The only solution is to save namespace from ANN and you can get the right fsimage.

      1. HDFS-7385.2.patch
        6 kB
        Chris Nauroth
      2. HDFS-7385.patch
        1 kB
        jiangyu

        Issue Links

          Activity

          Hide
          jiangyu1211 jiangyu added a comment -

          I think we should set null if we don't have any AclEntries in LogMkdir and LogOpenFiles functions. Sorry, i still use Svn, i didn't paste any patch on it.

          Show
          jiangyu1211 jiangyu added a comment - I think we should set null if we don't have any AclEntries in LogMkdir and LogOpenFiles functions. Sorry, i still use Svn, i didn't paste any patch on it.
          Hide
          jiangyu1211 jiangyu added a comment -

          These problem still exists in trunk.

          Show
          jiangyu1211 jiangyu added a comment - These problem still exists in trunk.
          Hide
          cmccabe Colin P. McCabe added a comment -

          Good find, jiangyu. In the future you might want to consider keeping the description short and putting the details of how you found the bug, etc. in the comments.

          It sounds like the problem here is that we are not calling op.setAclEntries in the case where there are no ACL entries? So the previous ACL entry from the thread-local Op gets used.

          Show
          cmccabe Colin P. McCabe added a comment - Good find, jiangyu . In the future you might want to consider keeping the description short and putting the details of how you found the bug, etc. in the comments. It sounds like the problem here is that we are not calling op.setAclEntries in the case where there are no ACL entries? So the previous ACL entry from the thread-local Op gets used.
          Hide
          jiangyu1211 jiangyu added a comment -

          That is right Colin, I think we should set null if there are no ACL entires. For now, this bug have messed up almost all the permissions in our cluster. It is easy to reproduce, just set some Acl Entries and mkdir randomly for some times, then after you restart the NameNode or transition SNN to ANN, you can find some directories permission are not what you expected easily. I wonder if there are no company use Acl Feature?

          Show
          jiangyu1211 jiangyu added a comment - That is right Colin, I think we should set null if there are no ACL entires. For now, this bug have messed up almost all the permissions in our cluster. It is easy to reproduce, just set some Acl Entries and mkdir randomly for some times, then after you restart the NameNode or transition SNN to ANN, you can find some directories permission are not what you expected easily. I wonder if there are no company use Acl Feature?
          Hide
          jiangyu1211 jiangyu added a comment -

          You can also use OfflineEditsViewer to find this bug easily.

          Show
          jiangyu1211 jiangyu added a comment - You can also use OfflineEditsViewer to find this bug easily.
          Hide
          cmccabe Colin P. McCabe added a comment -

          Sounds good. Are you working on a patch for this one?

          Show
          cmccabe Colin P. McCabe added a comment - Sounds good. Are you working on a patch for this one?
          Hide
          jiangyu1211 jiangyu added a comment -

          Here is the patch for trunk. Hadoop 2.4 don't have the feature of XAttrs, but i think it still face the same problem. I'm sorry i didn't write any unit test for it.

          Show
          jiangyu1211 jiangyu added a comment - Here is the patch for trunk. Hadoop 2.4 don't have the feature of XAttrs, but i think it still face the same problem. I'm sorry i didn't write any unit test for it.
          Hide
          jiangyu1211 jiangyu added a comment -

          For the users who apply ACL in their clusters , the permission of the directories and files should be messed up already. I suggest they should resolve this problem immediately. Firstly, apply the patch and enter sefemode and saveNamespace in ANN, then copy meta data to SNN, restart SNN and transition to ANN, and restart former ANN.

          Show
          jiangyu1211 jiangyu added a comment - For the users who apply ACL in their clusters , the permission of the directories and files should be messed up already. I suggest they should resolve this problem immediately. Firstly, apply the patch and enter sefemode and saveNamespace in ANN, then copy meta data to SNN, restart SNN and transition to ANN, and restart former ANN.
          Hide
          hitliuyi Yi Liu added a comment -

          jiangyu, good find, I think it's a critical issue. It should occur if multi-ops of create file (mkdir) happens using same thread.

          Please add a test case to reproduce it, it's not hard.

          Show
          hitliuyi Yi Liu added a comment - jiangyu , good find, I think it's a critical issue. It should occur if multi-ops of create file (mkdir) happens using same thread. Please add a test case to reproduce it, it's not hard.
          Hide
          jiangyu1211 jiangyu added a comment -

          Yi Liu, it also occur when open files, the same reason of using the ThreadLocal variable cache as mkdir . I will add test case later on.

          Show
          jiangyu1211 jiangyu added a comment - Yi Liu , it also occur when open files, the same reason of using the ThreadLocal variable cache as mkdir . I will add test case later on.
          Hide
          hitliuyi Yi Liu added a comment -

          jiangyu, OP_ADD is for create/append file, although you see the name "logOpenFile"
          Please add the test case as soon as possible, I will help to review and try to push it into 2.6, since I think the issue is critical, although the fix is easy.

          Show
          hitliuyi Yi Liu added a comment - jiangyu , OP_ADD is for create/append file, although you see the name "logOpenFile" Please add the test case as soon as possible, I will help to review and try to push it into 2.6, since I think the issue is critical, although the fix is easy.
          Hide
          vinayrpet Vinayakumar B added a comment -

          Hi jiangyu, Good find.

          Instead of op.setAclEntries(null) and op.setXAttrs(null), how about introducing a reset() method in both AddOp and MkdirOp which will reset all values to null. This method can be called as soon as get from the ThreadLocal cache and later setters can set the value whatever they want.
          This will avoid, any such mistakes in future.

          Ex:

              MkdirOp op = MkdirOp.getInstance(cache.get())
                .reset()
                .setInodeId(newNode.getId())
                .setPath(path)
                .setTimestamp(newNode.getModificationTime())
                .setPermissionStatus(permissions);
          
          Show
          vinayrpet Vinayakumar B added a comment - Hi jiangyu , Good find. Instead of op.setAclEntries(null) and op.setXAttrs(null) , how about introducing a reset() method in both AddOp and MkdirOp which will reset all values to null. This method can be called as soon as get from the ThreadLocal cache and later setters can set the value whatever they want. This will avoid, any such mistakes in future. Ex: MkdirOp op = MkdirOp.getInstance(cache.get()) .reset() .setInodeId(newNode.getId()) .setPath(path) .setTimestamp(newNode.getModificationTime()) .setPermissionStatus(permissions);
          Hide
          cnauroth Chris Nauroth added a comment -

          Hello, jiangyu. Like others have already said, this is a great find, and thank you for reporting it. Sorry for jumping in, but I want to expedite getting this fixed, so I'm attaching a v2 patch. I still intend to credit the patch to you. You did the hard part.

          I agree with the suggestions to add a test and add a reset method to the ops. I'm uploading a patch that does that. The test works by configuring a single RPC handler thread, which guarantees that all transactions get processed on the same thread, and therefore hit the same thread-local storage.

          Yi Liu or Vinayakumar B, how does this look?

          Show
          cnauroth Chris Nauroth added a comment - Hello, jiangyu . Like others have already said, this is a great find, and thank you for reporting it. Sorry for jumping in, but I want to expedite getting this fixed, so I'm attaching a v2 patch. I still intend to credit the patch to you. You did the hard part. I agree with the suggestions to add a test and add a reset method to the ops. I'm uploading a patch that does that. The test works by configuring a single RPC handler thread, which guarantees that all transactions get processed on the same thread, and therefore hit the same thread-local storage. Yi Liu or Vinayakumar B , how does this look?
          Hide
          vinayrpet Vinayakumar B added a comment -

          +1, patch looks good to me.
          Pending Jenkins +1.

          Show
          vinayrpet Vinayakumar B added a comment - +1, patch looks good to me. Pending Jenkins +1.
          Hide
          cnauroth Chris Nauroth added a comment -

          General consensus is that this is severe enough to hold the 2.6.0 release candidate, so I'm marking it a blocker. At this point, we're just waiting on Jenkins.

          Show
          cnauroth Chris Nauroth added a comment - General consensus is that this is severe enough to hold the 2.6.0 release candidate, so I'm marking it a blocker. At this point, we're just waiting on Jenkins.
          Hide
          hadoopqa Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12681364/HDFS-7385.2.patch
          against trunk revision 3651fe1.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 1 new or modified test files.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. There were no new javadoc warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed these unit tests in hadoop-hdfs-project/hadoop-hdfs:

          org.apache.hadoop.hdfs.TestDFSUpgradeFromImage
          org.apache.hadoop.hdfs.server.namenode.TestCacheDirectives

          The following test timeouts occurred in hadoop-hdfs-project/hadoop-hdfs:

          org.apache.hadoop.hdfs.util.TestByteArrayManager

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/8730//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/8730//console

          This message is automatically generated.

          Show
          hadoopqa Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12681364/HDFS-7385.2.patch against trunk revision 3651fe1. +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 2.0.3) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. -1 core tests . The patch failed these unit tests in hadoop-hdfs-project/hadoop-hdfs: org.apache.hadoop.hdfs.TestDFSUpgradeFromImage org.apache.hadoop.hdfs.server.namenode.TestCacheDirectives The following test timeouts occurred in hadoop-hdfs-project/hadoop-hdfs: org.apache.hadoop.hdfs.util.TestByteArrayManager +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/8730//testReport/ Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/8730//console This message is automatically generated.
          Hide
          cnauroth Chris Nauroth added a comment -

          For TestCacheDirectives, it looks like we hit one of the build collision issues we've seen on Jenkins lately, resulting in a NoClassDefFoundError. The other failures are unrelated issues that are tracked in other jiras. The failures did not repro locally for me. I'm going to commit this.

          Show
          cnauroth Chris Nauroth added a comment - For TestCacheDirectives , it looks like we hit one of the build collision issues we've seen on Jenkins lately, resulting in a NoClassDefFoundError . The other failures are unrelated issues that are tracked in other jiras. The failures did not repro locally for me. I'm going to commit this.
          Hide
          jiangyu1211 jiangyu added a comment -

          Thank you Chris Nauroth, the patch looks good to me. I also write a unit test for this bug, looks the same as you (but not that elegant), just set the handler to 1. I also wonder if we should advise some procedures to help the users who apply Acls already to save their meta data.

          Show
          jiangyu1211 jiangyu added a comment - Thank you Chris Nauroth , the patch looks good to me. I also write a unit test for this bug, looks the same as you (but not that elegant), just set the handler to 1. I also wonder if we should advise some procedures to help the users who apply Acls already to save their meta data.
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-trunk-Commit #6538 (See https://builds.apache.org/job/Hadoop-trunk-Commit/6538/)
          HDFS-7385. ThreadLocal used in FSEditLog class causes FSImage permission mess up. Contributed by jiangyu. (cnauroth: rev b0a41de68c5b08f534ca231293de053c0b0cbd5d)

          • hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java
          • hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java
          • hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestEditLog.java
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-trunk-Commit #6538 (See https://builds.apache.org/job/Hadoop-trunk-Commit/6538/ ) HDFS-7385 . ThreadLocal used in FSEditLog class causes FSImage permission mess up. Contributed by jiangyu. (cnauroth: rev b0a41de68c5b08f534ca231293de053c0b0cbd5d) hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestEditLog.java
          Hide
          cnauroth Chris Nauroth added a comment -

          I committed this to trunk, branch-2, branch-2.6 and branch-2.6.0. jiangyu, thank you again for reporting the issue and providing a patch.

          I also wonder if we should advise some procedures to help the users who apply Acls already to save their meta data.

          Yes, we can document a workaround here in the jira. If I understand correctly, your suggested workaround is running hdfs dfsadmin -saveNamespace at the active to force correct persistence of all inodes to the fsimage, thus bypassing the buggy edits. Do I have it correct?

          Show
          cnauroth Chris Nauroth added a comment - I committed this to trunk, branch-2, branch-2.6 and branch-2.6.0. jiangyu , thank you again for reporting the issue and providing a patch. I also wonder if we should advise some procedures to help the users who apply Acls already to save their meta data. Yes, we can document a workaround here in the jira. If I understand correctly, your suggested workaround is running hdfs dfsadmin -saveNamespace at the active to force correct persistence of all inodes to the fsimage, thus bypassing the buggy edits. Do I have it correct?
          Hide
          jiangyu1211 jiangyu added a comment -

          That is right, Chris Nauroth. The fsimage transfer from standby is already messed up. So we have to run hdfs dfsadmin -saveNamespace to get the correct persistence of all inodes to the fsimage.

          Show
          jiangyu1211 jiangyu added a comment - That is right, Chris Nauroth . The fsimage transfer from standby is already messed up. So we have to run hdfs dfsadmin -saveNamespace to get the correct persistence of all inodes to the fsimage.
          Hide
          cnauroth Chris Nauroth added a comment -

          I agree. The workaround makes sense. Thanks again!

          Show
          cnauroth Chris Nauroth added a comment - I agree. The workaround makes sense. Thanks again!
          Hide
          cmccabe Colin P. McCabe added a comment -

          Thanks, Chris Nauroth, for the patch! And thanks again to jiangyu for finding this.

          Show
          cmccabe Colin P. McCabe added a comment - Thanks, Chris Nauroth , for the patch! And thanks again to jiangyu for finding this.
          Hide
          jira.shegalov Gera Shegalov added a comment -

          It may be cleaner to introduce an abstract FSEditLogOp#reset() and call it in FSEditLog#logEdit(FSEditLogOp) that all ops need to override.

                try {
                  editLogStream.write(op);
                } catch (IOException ex) {
                  // All journals failed, it is handled in logSync.
                } finally {
                  op.reset();
                }
          

          to catch similar problems with garbage sitting in TLS in the future.

          Show
          jira.shegalov Gera Shegalov added a comment - It may be cleaner to introduce an abstract FSEditLogOp#reset() and call it in FSEditLog#logEdit(FSEditLogOp) that all ops need to override. try { editLogStream.write(op); } catch (IOException ex) { // All journals failed, it is handled in logSync. } finally { op.reset(); } to catch similar problems with garbage sitting in TLS in the future.
          Hide
          cnauroth Chris Nauroth added a comment -

          Hi, Gera Shegalov. Yes, I had the same thought, but I wanted to keep the patch here small and focused on the known problem, since we were hoping to include it in the 2.6.0 release candidate quickly. Please do feel free to file a subsequent jira for further refactoring targeting 2.7.0. Thanks!

          Show
          cnauroth Chris Nauroth added a comment - Hi, Gera Shegalov . Yes, I had the same thought, but I wanted to keep the patch here small and focused on the known problem, since we were hoping to include it in the 2.6.0 release candidate quickly. Please do feel free to file a subsequent jira for further refactoring targeting 2.7.0. Thanks!
          Hide
          cmccabe Colin P. McCabe added a comment -

          +1 for the idea of having a generic Op reset.

          Of course, we could easily run into the same problem of forgetting to reset fields in reset, but it will at least make things a little clearer.

          Show
          cmccabe Colin P. McCabe added a comment - +1 for the idea of having a generic Op reset. Of course, we could easily run into the same problem of forgetting to reset fields in reset, but it will at least make things a little clearer.
          Hide
          jira.shegalov Gera Shegalov added a comment -

          Thanks for feedback, Chris and Colin! I'll create a follow-up JIRA.

          Show
          jira.shegalov Gera Shegalov added a comment - Thanks for feedback, Chris and Colin! I'll create a follow-up JIRA.
          Hide
          cnauroth Chris Nauroth added a comment -

          On a side note, I have to wonder if the thread-local storage here is an unnecessary optimization at this point. It might be interesting to tear it down and just let the edit logging code paths create new short-lived instances that likely never leave eden. We could compare JIT assembly output before and after to see if it really makes a difference.

          Show
          cnauroth Chris Nauroth added a comment - On a side note, I have to wonder if the thread-local storage here is an unnecessary optimization at this point. It might be interesting to tear it down and just let the edit logging code paths create new short-lived instances that likely never leave eden. We could compare JIT assembly output before and after to see if it really makes a difference.
          Hide
          hitliuyi Yi Liu added a comment - - edited

          Thanks Chris for supplying the updated patch. Hmm, I also thought we need to expedite the fix and helped on update the patch.
          And thanks jiangyu for good find and initial patch, also thank Colin and Vinay for review

          Show
          hitliuyi Yi Liu added a comment - - edited Thanks Chris for supplying the updated patch. Hmm, I also thought we need to expedite the fix and helped on update the patch. And thanks jiangyu for good find and initial patch, also thank Colin and Vinay for review
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Yarn-trunk-Java8 #5 (See https://builds.apache.org/job/Hadoop-Yarn-trunk-Java8/5/)
          HDFS-7385. ThreadLocal used in FSEditLog class causes FSImage permission mess up. Contributed by jiangyu. (cnauroth: rev b0a41de68c5b08f534ca231293de053c0b0cbd5d)

          • hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java
          • hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java
          • hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestEditLog.java
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Yarn-trunk-Java8 #5 (See https://builds.apache.org/job/Hadoop-Yarn-trunk-Java8/5/ ) HDFS-7385 . ThreadLocal used in FSEditLog class causes FSImage permission mess up. Contributed by jiangyu. (cnauroth: rev b0a41de68c5b08f534ca231293de053c0b0cbd5d) hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestEditLog.java
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Hadoop-Yarn-trunk #743 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/743/)
          HDFS-7385. ThreadLocal used in FSEditLog class causes FSImage permission mess up. Contributed by jiangyu. (cnauroth: rev b0a41de68c5b08f534ca231293de053c0b0cbd5d)

          • hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java
          • hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestEditLog.java
          • hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Hadoop-Yarn-trunk #743 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/743/ ) HDFS-7385 . ThreadLocal used in FSEditLog class causes FSImage permission mess up. Contributed by jiangyu. (cnauroth: rev b0a41de68c5b08f534ca231293de053c0b0cbd5d) hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestEditLog.java hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Hadoop-Hdfs-trunk #1933 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1933/)
          HDFS-7385. ThreadLocal used in FSEditLog class causes FSImage permission mess up. Contributed by jiangyu. (cnauroth: rev b0a41de68c5b08f534ca231293de053c0b0cbd5d)

          • hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java
          • hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestEditLog.java
          • hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java
          • hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Hadoop-Hdfs-trunk #1933 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1933/ ) HDFS-7385 . ThreadLocal used in FSEditLog class causes FSImage permission mess up. Contributed by jiangyu. (cnauroth: rev b0a41de68c5b08f534ca231293de053c0b0cbd5d) hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestEditLog.java hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Hadoop-Hdfs-trunk-Java8 #5 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Java8/5/)
          HDFS-7385. ThreadLocal used in FSEditLog class causes FSImage permission mess up. Contributed by jiangyu. (cnauroth: rev b0a41de68c5b08f534ca231293de053c0b0cbd5d)

          • hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestEditLog.java
          • hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java
          • hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Hadoop-Hdfs-trunk-Java8 #5 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Java8/5/ ) HDFS-7385 . ThreadLocal used in FSEditLog class causes FSImage permission mess up. Contributed by jiangyu. (cnauroth: rev b0a41de68c5b08f534ca231293de053c0b0cbd5d) hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestEditLog.java hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Mapreduce-trunk #1957 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1957/)
          HDFS-7385. ThreadLocal used in FSEditLog class causes FSImage permission mess up. Contributed by jiangyu. (cnauroth: rev b0a41de68c5b08f534ca231293de053c0b0cbd5d)

          • hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java
          • hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java
          • hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestEditLog.java
          • hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Mapreduce-trunk #1957 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1957/ ) HDFS-7385 . ThreadLocal used in FSEditLog class causes FSImage permission mess up. Contributed by jiangyu. (cnauroth: rev b0a41de68c5b08f534ca231293de053c0b0cbd5d) hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestEditLog.java hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Hadoop-Mapreduce-trunk-Java8 #5 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Java8/5/)
          HDFS-7385. ThreadLocal used in FSEditLog class causes FSImage permission mess up. Contributed by jiangyu. (cnauroth: rev b0a41de68c5b08f534ca231293de053c0b0cbd5d)

          • hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestEditLog.java
          • hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java
          • hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Hadoop-Mapreduce-trunk-Java8 #5 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Java8/5/ ) HDFS-7385 . ThreadLocal used in FSEditLog class causes FSImage permission mess up. Contributed by jiangyu. (cnauroth: rev b0a41de68c5b08f534ca231293de053c0b0cbd5d) hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestEditLog.java hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLog.java hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSEditLogOp.java

            People

            • Assignee:
              jiangyu1211 jiangyu
              Reporter:
              jiangyu1211 jiangyu
            • Votes:
              0 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved:

                Development