Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: HA branch (HDFS-1623)
    • Fix Version/s: None
    • Component/s: ha, test
    • Labels:
      None

      Description

      TestDFSUtil is failing.

      org.junit.ComparisonFailure: expected:<ns1-nn1.example.com[]:8020> but was:<ns1-nn1.example.com[/220.250.64.24]:8020>
      	at org.junit.Assert.assertEquals(Assert.java:123)
      	at org.junit.Assert.assertEquals(Assert.java:145)
      	at org.apache.hadoop.hdfs.TestDFSUtil.testHANameNodesWithFederation(TestDFSUtil.java:411)
      

        Activity

        Hide
        Daryn Sharp added a comment -

        Trying to stub out dns was one of the very first things I tried to do when I joined the project. I had wildcard dns causing tests to fail with excruciating delays because IPC.Client has a hardcoded 45 retries for SocketTimeoutException. I think it will take JNDI which is where I gave up.

        PS. What's even funnier is how the tests pound on the real foo.com!

        Show
        Daryn Sharp added a comment - Trying to stub out dns was one of the very first things I tried to do when I joined the project. I had wildcard dns causing tests to fail with excruciating delays because IPC.Client has a hardcoded 45 retries for SocketTimeoutException . I think it will take JNDI which is where I gave up. PS. What's even funnier is how the tests pound on the real foo.com!
        Hide
        Uma Maheswara Rao G added a comment -

        Yea, its not an easy to control. and also may not be worth doing. I too agree with you to resolve the issue.

        After the analysis, found that this issue is related to DNS resolution and mocking the DNS resolution layer may not be worth doing now. So, marking it as won't fix.

        Show
        Uma Maheswara Rao G added a comment - Yea, its not an easy to control. and also may not be worth doing. I too agree with you to resolve the issue. After the analysis, found that this issue is related to DNS resolution and mocking the DNS resolution layer may not be worth doing now. So, marking it as won't fix.
        Hide
        Todd Lipcon added a comment -

        I think we have a couple other cases in the Hadoop tests that have this problem as well. I'm inclined to resolve this as wontfix, since actually mocking out the DNS resolution is not easy.

        Show
        Todd Lipcon added a comment - I think we have a couple other cases in the Hadoop tests that have this problem as well. I'm inclined to resolve this as wontfix, since actually mocking out the DNS resolution is not easy.
        Hide
        Uma Maheswara Rao G added a comment -

        Todd, Looks you are correct.
        I am not sure about the network here (in china).Just using WiFI available in Hotel.
        When i dig into it, looks 'x.' pattern is automatically resolving to that ip.

        org.junit.ComparisonFailure: expected:<x.[]:8020> but was:<x.[/<XXX.XXX.XX.XX>]:8020>
        at org.junit.Assert.assertEquals(Assert.java:123)
        at org.junit.Assert.assertEquals(Assert.java:145)
        at org.apache.hadoop.hdfs.TestDFSUtil.testHANameNodesWithFederation(TestDFSUtil.java:411)

        InetAddress.getByName("a.b") can give the same result.

        Also when i verified in my work PC, it is passing.

        Thanks
        Uma

        Show
        Uma Maheswara Rao G added a comment - Todd, Looks you are correct. I am not sure about the network here (in china).Just using WiFI available in Hotel. When i dig into it, looks 'x.' pattern is automatically resolving to that ip. org.junit.ComparisonFailure: expected:<x.[]:8020> but was:<x. [/<XXX.XXX.XX.XX>] :8020> at org.junit.Assert.assertEquals(Assert.java:123) at org.junit.Assert.assertEquals(Assert.java:145) at org.apache.hadoop.hdfs.TestDFSUtil.testHANameNodesWithFederation(TestDFSUtil.java:411) InetAddress.getByName("a.b") can give the same result. Also when i verified in my work PC, it is passing. Thanks Uma
        Hide
        Todd Lipcon added a comment -

        Odd, that IP is part of "China Unicom". Do you have wildcard DNS on your network?

        Show
        Todd Lipcon added a comment - Odd, that IP is part of "China Unicom". Do you have wildcard DNS on your network?

          People

          • Assignee:
            Uma Maheswara Rao G
            Reporter:
            Uma Maheswara Rao G
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development