Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 0.20.1
    • Fix Version/s: None
    • Component/s: test
    • Labels:
      None
    • Environment:

      Description

      TestReduceFetch is failing on one of our QA machines

        Issue Links

          Activity

          Aaron Kimball made changes -
          Link This issue duplicates MAPREDUCE-1172 [ MAPREDUCE-1172 ]
          Aaron Kimball made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Duplicate [ 3 ]
          Hide
          Aaron Kimball added a comment -

          Yes, it seems that is the case.

          Show
          Aaron Kimball added a comment - Yes, it seems that is the case.
          Aaron Kimball made changes -
          Field Original Value New Value
          Link This issue relates to HADOOP-4302 [ HADOOP-4302 ]
          Hide
          Aaron Kimball added a comment -

          On one of our QA clusters, we see consistent failure of TestReduceFetch.testReduceFromPartialMem(). A git-bisect revealed that the original test as added by HADOOP-3446 passes, but the "fix" implemented in HADOOP-4302 causes it to fail. Note that other machines (both 32- and 64-bit) do not experience the test failure.

          The dialogue in HADOOP-4302 says that the test is still race-prone, and that the "fix" in HADOOP-4302 tweaked some parameters in an attempt to make such conditions less likely. Is it possible to move these parameters into a better position that would make this even less likely? (I don't fully understand the relationship between them all and this test.)

          Ultimately, it would be good to completely refactor the test into one that's deterministic. As is, it's hard to tell what we learn from a failure in this test suite.

          Show
          Aaron Kimball added a comment - On one of our QA clusters, we see consistent failure of TestReduceFetch.testReduceFromPartialMem(). A git-bisect revealed that the original test as added by HADOOP-3446 passes, but the "fix" implemented in HADOOP-4302 causes it to fail. Note that other machines (both 32- and 64-bit) do not experience the test failure. The dialogue in HADOOP-4302 says that the test is still race-prone, and that the "fix" in HADOOP-4302 tweaked some parameters in an attempt to make such conditions less likely. Is it possible to move these parameters into a better position that would make this even less likely? (I don't fully understand the relationship between them all and this test.) Ultimately, it would be good to completely refactor the test into one that's deterministic. As is, it's hard to tell what we learn from a failure in this test suite.
          Hide
          Tsz Wo Nicholas Sze added a comment -

          Duplicate MAPREDUCE-1172?

          Show
          Tsz Wo Nicholas Sze added a comment - Duplicate MAPREDUCE-1172 ?
          Aaron Kimball created issue -

            People

            • Assignee:
              Unassigned
              Reporter:
              Aaron Kimball
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development