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

Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.0-alpha1
    • Fix Version/s: 2.8.0, 3.0.0-alpha1
    • Component/s: None
    • Labels:
      None
    • Target Version/s:
    • Hadoop Flags:
      Reviewed

      Description

      In certain cases, higher-priority under-replicated blocks can be skipped by the replication policy implementation. The current implementation maintains, for each priority level, an index into a list of blocks that are under-replicated. Together, the lists compose a priority queue (see note later about branch-0.23). In some cases when blocks are removed from a list, the caller (BlockManager) properly handles the index into the list from which it removed a block. In some other cases, the index remains stationary while the list changes. Whenever this happens, and the removed block happened to be at or before the index, the implementation will skip over a block when selecting blocks for replication work.

      In situations when entire racks are decommissioned, leading to many under-replicated blocks, loss of blocks can occur.

      Background: HDFS-1765

      This patch to trunk greatly improved the state of the replication policy implementation. Prior to the patch, the following details were true:

      • The block "priority queue" was no such thing: It was really set of trees that held blocks in natural ordering, that being by the blocks ID, which resulted in iterator walks over the blocks in pseudo-random order.
      • There was only a single index into an iteration over all of the blocks...
      • ... meaning the implementation was only successful in respecting priority levels on the first pass. Overall, the behavior was a round-robin-type scheduling of blocks.

      After the patch

      • A proper priority queue is implemented, preserving log n operations while iterating over blocks in the order added.
      • A separate index for each priority is key is kept...
      • ... allowing for processing of the highest priority blocks first regardless of which priority had last been processed.

      The change was suggested for branch-0.23 as well as trunk, but it does not appear to have been pulled in.

      The problem:

      Although the indices are now tracked in a better way, there is a synchronization issue since the indices are managed outside of methods to modify the contents of the queue.

      Removal of a block from a priority level without adjusting the index can mean that the index then points to the block after the block it originally pointed to. In the next round of scheduling for that priority level, the block originally pointed to by the index is skipped.

      1. HDFS-4366.patch
        23 kB
        Derek Dagit
      2. HDFS-4366.patch
        23 kB
        Derek Dagit
      3. HDFS-4366.patch
        13 kB
        Derek Dagit
      4. HDFS-4366.patch
        11 kB
        Derek Dagit
      5. HDFS-4366.patch
        9 kB
        Derek Dagit
      6. HDFS-4366.patch
        9 kB
        Derek Dagit
      7. HDFS-4366-branch-2.patch
        23 kB
        Haohui Mai
      8. hdfs-4366-unittest.patch
        5 kB
        Derek Dagit

        Issue Links

          Activity

          Hide
          dagit Derek Dagit added a comment -

          My initial thought is to encapsulate the priority indices inside UnderReplicatedBlocks, which is where the priority queue and indices live anyway.

          We could also guarantee the appropriate index is decremented properly on each call to remove.

          I do not think we can know in most cases whether a particular block lies to the left or right of the index since the random look-up of blocks is implemented as a hash, whereas the index is an index into a doubly-linked list. We would have to walk from the head or tail of the doubly-linked list to find the answer.

          Also, decrementing when we do not have to is not dangerous, since at worst it means we re-process a block that we would not have had to otherwise. But we should also make sure to clamp the index at 0 to avoid unnecessary processing. Currently with the patch, the index can go negative.

          Comments welcome

          Show
          dagit Derek Dagit added a comment - My initial thought is to encapsulate the priority indices inside UnderReplicatedBlocks, which is where the priority queue and indices live anyway. We could also guarantee the appropriate index is decremented properly on each call to remove. I do not think we can know in most cases whether a particular block lies to the left or right of the index since the random look-up of blocks is implemented as a hash, whereas the index is an index into a doubly-linked list. We would have to walk from the head or tail of the doubly-linked list to find the answer. Also, decrementing when we do not have to is not dangerous, since at worst it means we re-process a block that we would not have had to otherwise. But we should also make sure to clamp the index at 0 to avoid unnecessary processing. Currently with the patch, the index can go negative. Comments welcome
          Hide
          kihwal Kihwal Lee added a comment -

          HDFS-1765 was checked in to branch-0.23 of that time, which later became branch-2. Current branch-0.23 was created from branch-0.23.2. Current branch-0.23 does not have it because HDFS-1765 was not merged to 0.23.2 at that time.

          Would you check whether the attached patch is what you intended to post?

          Show
          kihwal Kihwal Lee added a comment - HDFS-1765 was checked in to branch-0.23 of that time, which later became branch-2. Current branch-0.23 was created from branch-0.23.2. Current branch-0.23 does not have it because HDFS-1765 was not merged to 0.23.2 at that time. Would you check whether the attached patch is what you intended to post?
          Hide
          dagit Derek Dagit added a comment -

          Replacing patch, as previous patch had extra unrelated changes.

          Show
          dagit Derek Dagit added a comment - Replacing patch, as previous patch had extra unrelated changes.
          Hide
          dagit Derek Dagit added a comment -

          Patch to encapsulate the indices within UnderReplicatedBlocks, and clamp the index to zero if negative.

          Any call to UnderReplicatedBlocks#remove will decrement the appropriate index for the priority.

          Show
          dagit Derek Dagit added a comment - Patch to encapsulate the indices within UnderReplicatedBlocks, and clamp the index to zero if negative. Any call to UnderReplicatedBlocks#remove will decrement the appropriate index for the priority.
          Hide
          dagit Derek Dagit added a comment -

          Not targeting for 0.23 since a number of other JIRAs, including HDFS-1765, are not yet in.

          Show
          dagit Derek Dagit added a comment - Not targeting for 0.23 since a number of other JIRAs, including HDFS-1765 , are not yet in.
          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/12564282/HDFS-4366.patch
          against trunk revision .

          +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. The javadoc tool did not generate any warning messages.

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

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) 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.server.balancer.TestBalancerWithNodeGroup

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

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3815//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3815//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/12564282/HDFS-4366.patch against trunk revision . +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 . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) 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.server.balancer.TestBalancerWithNodeGroup +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3815//testReport/ Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3815//console This message is automatically generated.
          Hide
          dagit Derek Dagit added a comment -

          A test timed out; probably transient.

          Uploading identical patch.

          Show
          dagit Derek Dagit added a comment - A test timed out; probably transient. Uploading identical patch.
          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/12564409/HDFS-4366.patch
          against trunk revision .

          +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. The javadoc tool did not generate any warning messages.

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

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

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

          +1 core tests. The patch passed unit tests in hadoop-hdfs-project/hadoop-hdfs.

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

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3822//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3822//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/12564409/HDFS-4366.patch against trunk revision . +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 . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-hdfs-project/hadoop-hdfs. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3822//testReport/ Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3822//console This message is automatically generated.
          Hide
          tlipcon Todd Lipcon added a comment -

          Hey Derek. Thanks for looking into this. I didn't check over the patch in detail yet, but one question:
          It seems like this managing of indexes is both error-prone (encourages bugs like this one) and inefficient (we have to scan from the start of the linked list, which is O).

          Instead of trying to patch the index updates, would it be better to just keep a reference to the LinkedElement (perhaps via the Iterator) so that we can just pick up where we left off with the list traversal? Seems like we might be better able to avoid bugs with that sort of design.

          Show
          tlipcon Todd Lipcon added a comment - Hey Derek. Thanks for looking into this. I didn't check over the patch in detail yet, but one question: It seems like this managing of indexes is both error-prone (encourages bugs like this one) and inefficient (we have to scan from the start of the linked list, which is O ). Instead of trying to patch the index updates, would it be better to just keep a reference to the LinkedElement (perhaps via the Iterator) so that we can just pick up where we left off with the list traversal? Seems like we might be better able to avoid bugs with that sort of design.
          Hide
          dagit Derek Dagit added a comment -

          That's a fair point. I think it can be better.

          A couple of ideas that were discussed:

          • Add a single "bookmark" reference to LightWeightLinkedSet, update the bookmark as necessary on modifications. Add a new method to make the bookmark available.
          • Maintain Iterators as weak references in LightWeightLinkedSet. On modification, purge dead references, and update the live references as necessary.

          I'll look at the bookmark idea, since it is more light-weight.

          Show
          dagit Derek Dagit added a comment - That's a fair point. I think it can be better. A couple of ideas that were discussed: Add a single "bookmark" reference to LightWeightLinkedSet, update the bookmark as necessary on modifications. Add a new method to make the bookmark available. Maintain Iterators as weak references in LightWeightLinkedSet. On modification, purge dead references, and update the live references as necessary. I'll look at the bookmark idea, since it is more light-weight.
          Hide
          tlipcon Todd Lipcon added a comment -

          Interleaved iteration and modification is only a problem if the node being iterated upon is the one that gets removed, right? Otherwise, we can still just follow its next pointer as long as the two things aren't actually concurrent.

          Given that, can we change UnderReplicatedBlocks to maintain the iterator, and on remove, if the iterator's current value is the block to be removed, to use iterator.remove() instead? The list of weak references sounds like it could get hairy fast.

          Show
          tlipcon Todd Lipcon added a comment - Interleaved iteration and modification is only a problem if the node being iterated upon is the one that gets removed, right? Otherwise, we can still just follow its next pointer as long as the two things aren't actually concurrent. Given that, can we change UnderReplicatedBlocks to maintain the iterator, and on remove, if the iterator's current value is the block to be removed, to use iterator.remove() instead? The list of weak references sounds like it could get hairy fast.
          Hide
          tlipcon Todd Lipcon added a comment -

          Alternatively, maybe we can refactor this to have its own data structure (LightWeightPriorityQueue) which we can more easily unit test, outside the context of blocks, etc?

          Show
          tlipcon Todd Lipcon added a comment - Alternatively, maybe we can refactor this to have its own data structure (LightWeightPriorityQueue) which we can more easily unit test, outside the context of blocks, etc?
          Hide
          dagit Derek Dagit added a comment -

          It's true that we care about is removal of the element to which the iterator points. (I think we also care if the set had been empty when the iterator was created, and then elements were added to the set in the meantime.)

          Two concerns:

          • The iterator throws ConcurrentModificationException if the set has been modified since the iterator was created. UnderReplicatedBlocks would need visibility into the iterator's internal modification version as well as the sets internal list in order to know the cases when the iterator's modification version should or should not be incremented on an add or remove to the set.
          • The behavior of the iterator is technically undefined if the set is modified without going through the iterator. Even if we do manage the above correctly, we are not supposed to expect capital-I Iterators to behave when we use them this way.

          It might be safer and cleaner to track the element in the set itself, so though we have coupling, at least it would be clearly defined via the methods provided. We could make a new class or make small modifications to the LightWeightLinkedSet.

          I agree about the weak references.

          Show
          dagit Derek Dagit added a comment - It's true that we care about is removal of the element to which the iterator points. (I think we also care if the set had been empty when the iterator was created, and then elements were added to the set in the meantime.) Two concerns: The iterator throws ConcurrentModificationException if the set has been modified since the iterator was created. UnderReplicatedBlocks would need visibility into the iterator's internal modification version as well as the sets internal list in order to know the cases when the iterator's modification version should or should not be incremented on an add or remove to the set. The behavior of the iterator is technically undefined if the set is modified without going through the iterator. Even if we do manage the above correctly, we are not supposed to expect capital-I Iterators to behave when we use them this way. It might be safer and cleaner to track the element in the set itself, so though we have coupling, at least it would be clearly defined via the methods provided. We could make a new class or make small modifications to the LightWeightLinkedSet. I agree about the weak references.
          Hide
          dagit Derek Dagit added a comment -

          Patch that removes the replication index and implements a bookmark instead.

          Show
          dagit Derek Dagit added a comment - Patch that removes the replication index and implements a bookmark instead.
          Hide
          dagit Derek Dagit added a comment -

          Submitted to activate the QA Bot.

          Comments welcome.

          Show
          dagit Derek Dagit added a comment - Submitted to activate the QA Bot. Comments welcome.
          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/12565229/HDFS-4366.patch
          against trunk revision .

          +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. The javadoc tool did not generate any warning messages.

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

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

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

          +1 core tests. The patch passed unit tests in hadoop-hdfs-project/hadoop-hdfs.

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

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3854//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3854//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/12565229/HDFS-4366.patch against trunk revision . +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 . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-hdfs-project/hadoop-hdfs. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3854//testReport/ Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3854//console This message is automatically generated.
          Hide
          tlipcon Todd Lipcon added a comment -

          This looks good to me. +1. Nice patch, Derek.

          I'll wait til tomorrow to commit in case anyone else wants to take a look - this is pretty important code so having a few eyes on it would be nice.

          Show
          tlipcon Todd Lipcon added a comment - This looks good to me. +1. Nice patch, Derek. I'll wait til tomorrow to commit in case anyone else wants to take a look - this is pretty important code so having a few eyes on it would be nice.
          Hide
          eli Eli Collins added a comment -

          Nice change Derek. This implementation is a much better implementation.

          • LightWeightLinkedSet#clear should reset the bookmark (via resetBookmark)
          • The chooseUnderReplicatedBlocks comment "Replication index will be tracked for each priority list separately in priorityToReplIdx map" should be updated per the new implementation. Ditto for "reset all priorities replication index to 0" farther down.
          • A one-line comment by neededReplicationsIterator.setToBookmark() to the effect of "Advance each iterator to the next unprocessed block at its priority level" would help
          • Perhaps in another jira, can you add a test to TestUnderReplicatedBlocks or TestUnderReplicatedBlockQueues that covers the case that you saw (triggered by decommissioning a rack)
          Show
          eli Eli Collins added a comment - Nice change Derek. This implementation is a much better implementation. LightWeightLinkedSet#clear should reset the bookmark (via resetBookmark) The chooseUnderReplicatedBlocks comment "Replication index will be tracked for each priority list separately in priorityToReplIdx map" should be updated per the new implementation. Ditto for "reset all priorities replication index to 0" farther down. A one-line comment by neededReplicationsIterator.setToBookmark() to the effect of "Advance each iterator to the next unprocessed block at its priority level" would help Perhaps in another jira, can you add a test to TestUnderReplicatedBlocks or TestUnderReplicatedBlockQueues that covers the case that you saw (triggered by decommissioning a rack)
          Hide
          dagit Derek Dagit added a comment -

          New patch to address comments:

          > LightWeightLinkedSet#clear should reset the bookmark (via resetBookmark)
          Good catch. I made this change and updated testClear to test for it.

          > The chooseUnderReplicatedBlocks comment "Replication index will be tracked for each priority list separately in priorityToReplIdx map" should be updated per the new implementation. Ditto for "reset all priorities replication index to 0" farther down.
          Updated comments in both places.

          > A one-line comment by neededReplicationsIterator.setToBookmark() to the effect of "Advance each iterator to the next unprocessed block at its priority level" would help
          Added

          > Perhaps in another jira, can you add a test to TestUnderReplicatedBlocks or TestUnderReplicatedBlockQueues that covers the case that you saw (triggered by decommissioning a rack)

          The problem we saw was really because we did not have HDFS-1765 in branch-23. I am assuming test written for that change will cover the scenario we saw, so we should get it when it is pulled into branch-23. If there is no test for it, we can write one.

          Show
          dagit Derek Dagit added a comment - New patch to address comments: > LightWeightLinkedSet#clear should reset the bookmark (via resetBookmark) Good catch. I made this change and updated testClear to test for it. > The chooseUnderReplicatedBlocks comment "Replication index will be tracked for each priority list separately in priorityToReplIdx map" should be updated per the new implementation. Ditto for "reset all priorities replication index to 0" farther down. Updated comments in both places. > A one-line comment by neededReplicationsIterator.setToBookmark() to the effect of "Advance each iterator to the next unprocessed block at its priority level" would help Added > Perhaps in another jira, can you add a test to TestUnderReplicatedBlocks or TestUnderReplicatedBlockQueues that covers the case that you saw (triggered by decommissioning a rack) The problem we saw was really because we did not have HDFS-1765 in branch-23. I am assuming test written for that change will cover the scenario we saw, so we should get it when it is pulled into branch-23. If there is no test for it, we can write one.
          Hide
          eli Eli Collins added a comment -

          +1 Thanks Derek, latest patch lgtm

          The problem we saw was really because we did not have HDFS-1765 in branch-23. I am assuming test written for that change will cover the scenario we saw

          Right, but looks like we're still missing a test for the fix here, iiuc your first patch here noted that we were failing to update the priority index in a couple of places which should mean we could write a test that would fail w/o this change because we weren't respecting priority right?

          Show
          eli Eli Collins added a comment - +1 Thanks Derek, latest patch lgtm The problem we saw was really because we did not have HDFS-1765 in branch-23. I am assuming test written for that change will cover the scenario we saw Right, but looks like we're still missing a test for the fix here, iiuc your first patch here noted that we were failing to update the priority index in a couple of places which should mean we could write a test that would fail w/o this change because we weren't respecting priority right?
          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/12566210/HDFS-4366.patch
          against trunk revision .

          +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. The javadoc tool did not generate any warning messages.

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

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

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

          +1 core tests. The patch passed unit tests in hadoop-hdfs-project/hadoop-hdfs.

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

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3875//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3875//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/12566210/HDFS-4366.patch against trunk revision . +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 . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-hdfs-project/hadoop-hdfs. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3875//testReport/ Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3875//console This message is automatically generated.
          Hide
          umamaheswararao Uma Maheswara Rao G added a comment -

          Thanks a lot, for working on this Derek.

          Right, but looks like we're still missing a test for the fix here, iiuc your first patch here noted that we were failing to update the priority index in a couple of places which should mean we could write a test that would fail w/o this change because we weren't respecting priority right?
          

          I agree with Eli. Here I also wanted to see a test for the case where you are seeing that we are missing to update index and but removing the element. All the updations to neededReplications out side mostly would be in namesystem lock. The chooseUnderReplicatedBlocks also will be processed under namesystem lock. That issue says that we missed somewhere to update that index. It would be great if you can add some test to cover that scenario. Otherwise we still miss to cover that case.

          Show
          umamaheswararao Uma Maheswara Rao G added a comment - Thanks a lot, for working on this Derek. Right, but looks like we're still missing a test for the fix here, iiuc your first patch here noted that we were failing to update the priority index in a couple of places which should mean we could write a test that would fail w/o this change because we weren't respecting priority right? I agree with Eli. Here I also wanted to see a test for the case where you are seeing that we are missing to update index and but removing the element. All the updations to neededReplications out side mostly would be in namesystem lock. The chooseUnderReplicatedBlocks also will be processed under namesystem lock. That issue says that we missed somewhere to update that index. It would be great if you can add some test to cover that scenario. Otherwise we still miss to cover that case.
          Hide
          dagit Derek Dagit added a comment -

          Right, I see your point. There hasn't been a test added that truly exposes the problem described.

          I'll add a test that exposes the specific issue and post a new patch.

          Show
          dagit Derek Dagit added a comment - Right, I see your point. There hasn't been a test added that truly exposes the problem described. I'll add a test that exposes the specific issue and post a new patch.
          Hide
          dagit Derek Dagit added a comment -

          Sorry for the delay; just started looking at this again.

          Attached a new patch. One minor change to set an ArrayList capacity for UnderReplicatedBlocks, and 4 new tests that expose the 4 original spots I identified as potentially harmful.

          Comments welcome.

          Show
          dagit Derek Dagit added a comment - Sorry for the delay; just started looking at this again. Attached a new patch. One minor change to set an ArrayList capacity for UnderReplicatedBlocks, and 4 new tests that expose the 4 original spots I identified as potentially harmful. Comments welcome.
          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/12572840/HDFS-4366.patch
          against trunk revision .

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

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

          -1 one of tests included doesn't have a timeout.

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

          +1 javadoc. The javadoc tool did not generate any warning messages.

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

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) 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.server.blockmanagement.TestReplicationPolicy

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

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4063//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4063//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/12572840/HDFS-4366.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 2 new or modified test files. -1 one of tests included doesn't have a timeout. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) 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.server.blockmanagement.TestReplicationPolicy +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4063//testReport/ Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4063//console This message is automatically generated.
          Hide
          dagit Derek Dagit added a comment -

          Updated patch to address QA Bot.

          Show
          dagit Derek Dagit added a comment - Updated patch to address QA Bot.
          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/12572930/HDFS-4366.patch
          against trunk revision .

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

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

          +1 tests included appear to have a timeout.

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

          +1 javadoc. The javadoc tool did not generate any warning messages.

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

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

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

          +1 core tests. The patch passed unit tests in hadoop-hdfs-project/hadoop-hdfs.

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

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4066//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4066//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/12572930/HDFS-4366.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 2 new or modified test files. +1 tests included appear to have a timeout. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-hdfs-project/hadoop-hdfs. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4066//testReport/ Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4066//console This message is automatically generated.
          Hide
          tlipcon Todd Lipcon added a comment -

          The latest patch looks good to me and looks like it still applies to trunk. Eli, Uma, any further comments, or should we commit this?

          Show
          tlipcon Todd Lipcon added a comment - The latest patch looks good to me and looks like it still applies to trunk. Eli, Uma, any further comments, or should we commit this?
          Hide
          dagit Derek Dagit added a comment -

          Thanks, Todd.

          I ran into some trouble earlier getting the tests to work on 0.23--I have a hunch it might have to do with the version of Mockito in 0.23, but I have not confirmed.

          I was planning on porting these tests for 0.23 if that would be a good thing.

          Show
          dagit Derek Dagit added a comment - Thanks, Todd. I ran into some trouble earlier getting the tests to work on 0.23--I have a hunch it might have to do with the version of Mockito in 0.23, but I have not confirmed. I was planning on porting these tests for 0.23 if that would be a good thing.
          Hide
          dagit Derek Dagit added a comment -

          Tests for the 0.23 branch will take a bit longer, so tracking the 0.23 branch change with HDFS-4696 to unblock this one.

          Show
          dagit Derek Dagit added a comment - Tests for the 0.23 branch will take a bit longer, so tracking the 0.23 branch change with HDFS-4696 to unblock this one.
          Hide
          dagit Derek Dagit added a comment -

          Anything else blocking this that I should look into?

          Show
          dagit Derek Dagit added a comment - Anything else blocking this that I should look into?
          Hide
          kihwal Kihwal Lee added a comment -

          I've committed this to trunk. Since it has been a while, I ran all HDFS tests and they all ran fine. Thanks for working on the patch Derek.

          Show
          kihwal Kihwal Lee added a comment - I've committed this to trunk. Since it has been a while, I ran all HDFS tests and they all ran fine. Thanks for working on the patch Derek.
          Hide
          kihwal Kihwal Lee added a comment -

          The patch didn't apply to branch-2. If anyone thinks it needs to be fixed in branch-2 as well, feel free to reopen.

          Show
          kihwal Kihwal Lee added a comment - The patch didn't apply to branch-2. If anyone thinks it needs to be fixed in branch-2 as well, feel free to reopen.
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Hadoop-trunk-Commit #4213 (See https://builds.apache.org/job/Hadoop-trunk-Commit/4213/)
          Fix CHANGES.txt. Move HDFS-4366 from 2.3.0 to under 3.0.0. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510727)

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
            HDFS-4366. Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks. Contributed by Derek Dagit. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510724)
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/UnderReplicatedBlocks.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/util/LightWeightLinkedSet.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/blockmanagement/TestReplicationPolicy.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/util/TestLightWeightLinkedSet.java
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Hadoop-trunk-Commit #4213 (See https://builds.apache.org/job/Hadoop-trunk-Commit/4213/ ) Fix CHANGES.txt. Move HDFS-4366 from 2.3.0 to under 3.0.0. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510727 ) /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt HDFS-4366 . Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks. Contributed by Derek Dagit. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510724 ) /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/UnderReplicatedBlocks.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/util/LightWeightLinkedSet.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/blockmanagement/TestReplicationPolicy.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/util/TestLightWeightLinkedSet.java
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Hadoop-Yarn-trunk #293 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/293/)
          Fix CHANGES.txt. Move HDFS-4366 from 2.3.0 to under 3.0.0. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510727)

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
            HDFS-4366. Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks. Contributed by Derek Dagit. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510724)
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/UnderReplicatedBlocks.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/util/LightWeightLinkedSet.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/blockmanagement/TestReplicationPolicy.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/util/TestLightWeightLinkedSet.java
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Hadoop-Yarn-trunk #293 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/293/ ) Fix CHANGES.txt. Move HDFS-4366 from 2.3.0 to under 3.0.0. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510727 ) /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt HDFS-4366 . Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks. Contributed by Derek Dagit. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510724 ) /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/UnderReplicatedBlocks.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/util/LightWeightLinkedSet.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/blockmanagement/TestReplicationPolicy.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/util/TestLightWeightLinkedSet.java
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Hdfs-trunk #1483 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1483/)
          Fix CHANGES.txt. Move HDFS-4366 from 2.3.0 to under 3.0.0. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510727)

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
            HDFS-4366. Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks. Contributed by Derek Dagit. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510724)
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/UnderReplicatedBlocks.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/util/LightWeightLinkedSet.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/blockmanagement/TestReplicationPolicy.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/util/TestLightWeightLinkedSet.java
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Hdfs-trunk #1483 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1483/ ) Fix CHANGES.txt. Move HDFS-4366 from 2.3.0 to under 3.0.0. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510727 ) /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt HDFS-4366 . Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks. Contributed by Derek Dagit. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510724 ) /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/UnderReplicatedBlocks.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/util/LightWeightLinkedSet.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/blockmanagement/TestReplicationPolicy.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/util/TestLightWeightLinkedSet.java
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Mapreduce-trunk #1510 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1510/)
          Fix CHANGES.txt. Move HDFS-4366 from 2.3.0 to under 3.0.0. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510727)

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
            HDFS-4366. Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks. Contributed by Derek Dagit. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510724)
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/UnderReplicatedBlocks.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/util/LightWeightLinkedSet.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/blockmanagement/TestReplicationPolicy.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/util/TestLightWeightLinkedSet.java
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Mapreduce-trunk #1510 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1510/ ) Fix CHANGES.txt. Move HDFS-4366 from 2.3.0 to under 3.0.0. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510727 ) /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt HDFS-4366 . Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks. Contributed by Derek Dagit. (kihwal: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1510724 ) /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/UnderReplicatedBlocks.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/util/LightWeightLinkedSet.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/blockmanagement/TestReplicationPolicy.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/util/TestLightWeightLinkedSet.java
          Hide
          wheat9 Haohui Mai added a comment -

          Uploaded a patch for branch-2.

          Show
          wheat9 Haohui Mai added a comment - Uploaded a patch for branch-2.
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-trunk-Commit #8045 (See https://builds.apache.org/job/Hadoop-trunk-Commit/8045/)
          Move HDFS-4366 to 2.8.0 in CHANGES.txt (wang: rev 5590e914f5889413da9eda047f64842c4b67fe85)

          • hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-trunk-Commit #8045 (See https://builds.apache.org/job/Hadoop-trunk-Commit/8045/ ) Move HDFS-4366 to 2.8.0 in CHANGES.txt (wang: rev 5590e914f5889413da9eda047f64842c4b67fe85) hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Hide
          andrew.wang Andrew Wang added a comment -

          Zhe Zhang did up a branch-2 patch which I backported, changing the fix version to reflect this.

          Show
          andrew.wang Andrew Wang added a comment - Zhe Zhang did up a branch-2 patch which I backported, changing the fix version to reflect this.
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Yarn-trunk #967 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/967/)
          Move HDFS-4366 to 2.8.0 in CHANGES.txt (wang: rev 5590e914f5889413da9eda047f64842c4b67fe85)

          • hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Yarn-trunk #967 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/967/ ) Move HDFS-4366 to 2.8.0 in CHANGES.txt (wang: rev 5590e914f5889413da9eda047f64842c4b67fe85) hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Hadoop-Yarn-trunk-Java8 #237 (See https://builds.apache.org/job/Hadoop-Yarn-trunk-Java8/237/)
          Move HDFS-4366 to 2.8.0 in CHANGES.txt (wang: rev 5590e914f5889413da9eda047f64842c4b67fe85)

          • hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Hadoop-Yarn-trunk-Java8 #237 (See https://builds.apache.org/job/Hadoop-Yarn-trunk-Java8/237/ ) Move HDFS-4366 to 2.8.0 in CHANGES.txt (wang: rev 5590e914f5889413da9eda047f64842c4b67fe85) hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Hdfs-trunk #2165 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/2165/)
          Move HDFS-4366 to 2.8.0 in CHANGES.txt (wang: rev 5590e914f5889413da9eda047f64842c4b67fe85)

          • hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Hdfs-trunk #2165 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/2165/ ) Move HDFS-4366 to 2.8.0 in CHANGES.txt (wang: rev 5590e914f5889413da9eda047f64842c4b67fe85) hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Hdfs-trunk-Java8 #226 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Java8/226/)
          Move HDFS-4366 to 2.8.0 in CHANGES.txt (wang: rev 5590e914f5889413da9eda047f64842c4b67fe85)

          • hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Hdfs-trunk-Java8 #226 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Java8/226/ ) Move HDFS-4366 to 2.8.0 in CHANGES.txt (wang: rev 5590e914f5889413da9eda047f64842c4b67fe85) hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Mapreduce-trunk-Java8 #235 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Java8/235/)
          Move HDFS-4366 to 2.8.0 in CHANGES.txt (wang: rev 5590e914f5889413da9eda047f64842c4b67fe85)

          • hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Mapreduce-trunk-Java8 #235 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Java8/235/ ) Move HDFS-4366 to 2.8.0 in CHANGES.txt (wang: rev 5590e914f5889413da9eda047f64842c4b67fe85) hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in Hadoop-Mapreduce-trunk #2183 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/2183/)
          Move HDFS-4366 to 2.8.0 in CHANGES.txt (wang: rev 5590e914f5889413da9eda047f64842c4b67fe85)

          • hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Show
          hudson Hudson added a comment - FAILURE: Integrated in Hadoop-Mapreduce-trunk #2183 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/2183/ ) Move HDFS-4366 to 2.8.0 in CHANGES.txt (wang: rev 5590e914f5889413da9eda047f64842c4b67fe85) hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt

            People

            • Assignee:
              dagit Derek Dagit
              Reporter:
              dagit Derek Dagit
            • Votes:
              0 Vote for this issue
              Watchers:
              17 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development