Uploaded image for project: 'Hadoop Common'
  1. Hadoop Common
  2. HADOOP-4387

TestHDFSFileSystemContract fails on windows

Details

    • Bug
    • Status: Closed
    • Blocker
    • Resolution: Fixed
    • None
    • 0.19.0
    • test
    • None
    • Reviewed

    Description

      'ant -Dtestcase=TestHDFSFileSystemContract test-core' fails on Windows nightly build machine.

      Not sure if this is Hadoop error or a configuration error particular to this machine. Basically the following assert fails :

          Path workDir = path(getDefaultWorkingDirectory());
          assertEquals(workDir, fs.getWorkingDirectory());
      

      This is essentially testing that System.getProperty("user.name") is same as string returned by Cygwin's 'whoami'. But in this case, these are "SYSTEM" and "hadoopqa" respectively.

      Attachments

        1. HADOOP-4387.patch
          1 kB
          Raghu Angadi

        Activity

          szetszwo Tsz-wo Sze added a comment -

          Should we make this a part of HADOOP-4171?

          szetszwo Tsz-wo Sze added a comment - Should we make this a part of HADOOP-4171 ?
          szetszwo Tsz-wo Sze added a comment -

          BTW, I cannot reproduce this in my Windows machine.

          [junit] Running org.apache.hadoop.hdfs.TestHDFSFileSystemContract
          [junit] Tests run: 25, Failures: 0, Errors: 0, Time elapsed: 195.906 sec
          
          szetszwo Tsz-wo Sze added a comment - BTW, I cannot reproduce this in my Windows machine. [junit] Running org.apache.hadoop.hdfs.TestHDFSFileSystemContract [junit] Tests run: 25, Failures: 0, Errors: 0, Time elapsed: 195.906 sec
          rangadi Raghu Angadi added a comment -

          Enis,

          Could you check this mismatch between how "user" name is calculated. You added this test quite sometime back.

          Same issue existed in Windows before in HADOOP-2523, but there the resolution was simpler : just removing the assert . Here, it seem like "user.name" is used in other places like S3.

          rangadi Raghu Angadi added a comment - Enis, Could you check this mismatch between how "user" name is calculated. You added this test quite sometime back. Same issue existed in Windows before in HADOOP-2523 , but there the resolution was simpler : just removing the assert . Here, it seem like "user.name" is used in other places like S3.
          rangadi Raghu Angadi added a comment -

          > Should we make this a part of HADOOP-4171?
          I don't think it is related.

          If anyone knows where JVM gets "user.name" on XP, please let us know.

          rangadi Raghu Angadi added a comment - > Should we make this a part of HADOOP-4171 ? I don't think it is related. If anyone knows where JVM gets "user.name" on XP, please let us know.
          enis Enis Soztutar added a comment -

          Raghu,
          Can you confirm that the bug could be the same one listed here :
          http://www.cvsnt.org/pipermail/cvsnt/2001-December/000057.html

          In this case, can you find a workaround?

          enis Enis Soztutar added a comment - Raghu, Can you confirm that the bug could be the same one listed here : http://www.cvsnt.org/pipermail/cvsnt/2001-December/000057.html In this case, can you find a workaround?
          rangadi Raghu Angadi added a comment -

          Will check.

          But I don't know what the motivation for this test is. All it is testing is 'whoami' and 'user.name' should have the same name.. HDFS does not depend on it.. so HDFS should not be tested for it. Could you explain what this tests?

          rangadi Raghu Angadi added a comment - Will check. But I don't know what the motivation for this test is. All it is testing is 'whoami' and 'user.name' should have the same name.. HDFS does not depend on it.. so HDFS should not be tested for it. Could you explain what this tests?
          enis Enis Soztutar added a comment -

          Well, TestHDFSFileSystemContract just extends FileSystemContractBase, which actually defines the tests, so it may not be meaningful for hdfs to testWorkingDir(), but for some other fs it may make sense.

          The tests are introduced in HADOOP-930 by Tom White. Tom, could you please check this?

          enis Enis Soztutar added a comment - Well, TestHDFSFileSystemContract just extends FileSystemContractBase, which actually defines the tests, so it may not be meaningful for hdfs to testWorkingDir(), but for some other fs it may make sense. The tests are introduced in HADOOP-930 by Tom White. Tom, could you please check this?
          rangadi Raghu Angadi added a comment -

          > TestHDFSFileSystemContract just extends FileSystemContractBase, which actually defines the tests, so it may not be meaningful for hdfs to testWorkingDir(),

          Right. Nicholas also had suggested overriding getDefaultWorkingDirectory() for HDFS. The attached patch does that. The test passes now.

          rangadi Raghu Angadi added a comment - > TestHDFSFileSystemContract just extends FileSystemContractBase, which actually defines the tests, so it may not be meaningful for hdfs to testWorkingDir(), Right. Nicholas also had suggested overriding getDefaultWorkingDirectory() for HDFS. The attached patch does that. The test passes now.
          szetszwo Tsz-wo Sze added a comment -

          +1 patch looks good.

          szetszwo Tsz-wo Sze added a comment - +1 patch looks good.
          rangadi Raghu Angadi added a comment -

          I just committed this.

          test-patch output :

               [exec] +1 overall.
          
               [exec]     +1 @author.  The patch does not contain any @author tags.
          
               [exec]     +1 tests included.  The patch appears to include 3 new or modified tests.
          
               [exec]     +1 javadoc.  The javadoc tool did not generate any warning messages.
          
               [exec]     +1 javac.  The applied patch does not increase the total number of javac compiler warnings.
          
               [exec]     +1 findbugs.  The patch does not introduce any new Findbugs warnings.
          
               [exec]     +1 Eclipse classpath. The patch retains Eclipse classpath integrity.
          
          rangadi Raghu Angadi added a comment - I just committed this. test-patch output : [exec] +1 overall. [exec] +1 @author. The patch does not contain any @author tags. [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] +1 findbugs. The patch does not introduce any new Findbugs warnings. [exec] +1 Eclipse classpath. The patch retains Eclipse classpath integrity.
          hudson Hudson added a comment -
          hudson Hudson added a comment - Integrated in Hadoop-trunk #640 (See http://hudson.zones.apache.org/hudson/job/Hadoop-trunk/640/ )

          People

            rangadi Raghu Angadi
            rangadi Raghu Angadi
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: