[jira] [Resolved] (HDFS-4696) Branch 0.23 Patch for "Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks"
[ https://issues.apache.org/jira/browse/HDFS-4696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit resolved HDFS-4696. --- Resolution: Won't Fix - Support for adding tests is not available in 0.23 - Fixed in 3.0.0 - Likelihood of this happening is very improbable even if not fixed. > Branch 0.23 Patch for "Block Replication Policy Implementation May Skip > Higher-Priority Blocks for Lower-Priority Blocks" > - > > Key: HDFS-4696 > URL: https://issues.apache.org/jira/browse/HDFS-4696 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit > > This JIRA tracks the solution to HDFS-4366 for the 0.23 branch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707064#comment-13707064 ] Derek Dagit commented on HDFS-4366: --- Anything else blocking this that I should look into? > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, > HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631779#comment-13631779 ] Derek Dagit commented on HDFS-4366: --- 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. > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, > HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HDFS-4696) Branch 0.23 Patch for "Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks"
Derek Dagit created HDFS-4696: - Summary: Branch 0.23 Patch for "Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks" Key: HDFS-4696 URL: https://issues.apache.org/jira/browse/HDFS-4696 Project: Hadoop HDFS Issue Type: Bug Affects Versions: 0.23.5 Reporter: Derek Dagit Assignee: Derek Dagit This JIRA tracks the solution to HDFS-4366 for the 0.23 branch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Affects Version/s: (was: 0.23.5) > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, > HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13624118#comment-13624118 ] Derek Dagit commented on HDFS-4366: --- 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. > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, > HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Attachment: HDFS-4366.patch Updated patch to address QA Bot. > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, > HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Status: Patch Available (was: Open) > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 0.23.5, 3.0.0 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, > HDFS-4366.patch, HDFS-4366.patch, hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Attachment: HDFS-4366.patch 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. > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, > HDFS-4366.patch, HDFS-4366.patch, hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Status: Open (was: Patch Available) 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. > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 0.23.5, 3.0.0 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, > HDFS-4366.patch, hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Attachment: HDFS-4366.patch 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. > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, > HDFS-4366.patch, hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Status: Patch Available (was: Open) Submitted to activate the QA Bot. Comments welcome. > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 0.23.5, 3.0.0 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, > hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Attachment: HDFS-4366.patch Patch that removes the replication index and implements a bookmark instead. > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, HDFS-4366.patch, HDFS-4366.patch, > hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13555171#comment-13555171 ] Derek Dagit commented on HDFS-4366: --- 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. > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, HDFS-4366.patch, > hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Status: Open (was: Patch Available) 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. > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 0.23.5, 3.0.0 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, HDFS-4366.patch, > hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Attachment: HDFS-4366.patch A test timed out; probably transient. Uploading identical patch. > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, HDFS-4366.patch, > hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Target Version/s: 3.0.0 Status: Patch Available (was: Open) Not targeting for 0.23 since a number of other JIRAs, including HDFS-1765, are not yet in. > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 0.23.5, 3.0.0 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Attachment: HDFS-4366.patch 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. > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: HDFS-4366.patch, hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Attachment: (was: hdfs-4366-unittest.patch) > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Attachment: hdfs-4366-unittest.patch Replacing patch, as previous patch had extra unrelated changes. > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Affects Version/s: (was: 1.1.1) > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- Attachment: hdfs-4366-unittest.patch 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 > Block Replication Policy Implementation May Skip Higher-Priority Blocks for > Lower-Priority Blocks > - > > Key: HDFS-4366 > URL: https://issues.apache.org/jira/browse/HDFS-4366 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 1.1.1, 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit > Attachments: hdfs-4366-unittest.patch > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
[ https://issues.apache.org/jira/browse/HDFS-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4366: -- 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. was: 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, t
[jira] [Created] (HDFS-4366) Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks
Derek Dagit created HDFS-4366: - Summary: Block Replication Policy Implementation May Skip Higher-Priority Blocks for Lower-Priority Blocks Key: HDFS-4366 URL: https://issues.apache.org/jira/browse/HDFS-4366 Project: Hadoop HDFS Issue Type: Bug Affects Versions: 0.23.5, 1.1.1, 3.0.0 Reporter: Derek Dagit Assignee: Derek Dagit 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4270: -- Attachment: HDFS-4270.patch New hard-limit config, defaults to 4. > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4270-branch-0.23.patch, > HDFS-4270-branch-0.23.patch, HDFS-4270.patch, HDFS-4270.patch, > HDFS-4270.patch, HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4270: -- Attachment: HDFS-4270-branch-0.23.patch New hard-limit config, defaults to 4. > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4270-branch-0.23.patch, > HDFS-4270-branch-0.23.patch, HDFS-4270.patch, HDFS-4270.patch, > HDFS-4270.patch, HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531452#comment-13531452 ] Derek Dagit commented on HDFS-4270: --- If we consider a hard limit, what should the limit be? > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4270-branch-0.23.patch, HDFS-4270.patch, > HDFS-4270.patch, HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4270: -- Attachment: HDFS-4270.patch Reattaching patch again. The balancer test failure looks like another spurious result. > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4270-branch-0.23.patch, HDFS-4270.patch, > HDFS-4270.patch, HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4270: -- Attachment: HDFS-4270.patch Re-attaching patch, as the errors reported by the bot appear to be transient. > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4270-branch-0.23.patch, HDFS-4270.patch, > HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4270: -- Status: Patch Available (was: Open) > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 0.23.5, 3.0.0 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4270-branch-0.23.patch, HDFS-4270.patch, > HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13528392#comment-13528392 ] Derek Dagit commented on HDFS-4270: --- Manually ran eclipse:eclipse -> works for me Manually ran TestEditLog.testFuzzSequences -> passes for me Javadoc error was a build error: connection timed out while fetching a dependency. > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4270-branch-0.23.patch, HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4270: -- Status: Open (was: Patch Available) Canceling patch for now. Later after discussion, I'll fix the errors and upload new patches. > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 0.23.5, 3.0.0 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4270-branch-0.23.patch, HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511534#comment-13511534 ] Derek Dagit commented on HDFS-4270: --- Hi Aaron, Noted. I meant to remove the entries in fixed, but I must have forgot. I'll try not to do that in the future. Hi Nicholas, I do see the concern over making this case unbounded, for the sake of the NN. I am interested, historically why was the default limit set to 2? > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4270-branch-0.23.patch, HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510608#comment-13510608 ] Derek Dagit commented on HDFS-4270: --- New patches add a second assert to the test, and fix some formatting/readability issues. > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Fix For: 3.0.0, 2.0.3-alpha, 0.23.6 > > Attachments: HDFS-4270-branch-0.23.patch, HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4270: -- Attachment: HDFS-4270.patch > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Fix For: 3.0.0, 2.0.3-alpha, 0.23.6 > > Attachments: HDFS-4270-branch-0.23.patch, HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4270: -- Attachment: (was: HDFS-4270.patch) > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Fix For: 3.0.0, 2.0.3-alpha, 0.23.6 > > Attachments: HDFS-4270-branch-0.23.patch, HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4270: -- Attachment: (was: HDFS-4270-branch-0.23.patch) > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Fix For: 3.0.0, 2.0.3-alpha, 0.23.6 > > Attachments: HDFS-4270-branch-0.23.patch, HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4270: -- Attachment: HDFS-4270-branch-0.23.patch > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Fix For: 3.0.0, 2.0.3-alpha, 0.23.6 > > Attachments: HDFS-4270-branch-0.23.patch, HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4270: -- Attachment: HDFS-4270.patch > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Fix For: 3.0.0, 2.0.3-alpha, 0.23.6 > > Attachments: HDFS-4270-branch-0.23.patch, HDFS-4270.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
[ https://issues.apache.org/jira/browse/HDFS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4270: -- Attachment: HDFS-4270-branch-0.23.patch > Replications of the highest priority should be allowed to choose a source > datanode that has reached its max replication limit > - > > Key: HDFS-4270 > URL: https://issues.apache.org/jira/browse/HDFS-4270 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 3.0.0, 0.23.5 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Fix For: 3.0.0, 2.0.3-alpha, 0.23.6 > > Attachments: HDFS-4270-branch-0.23.patch > > > Blocks that have been identified as under-replicated are placed on one of > several priority queues. The highest priority queue is essentially reserved > for situations in which only one replica of the block exists, meaning it > should be replicated ASAP. > The ReplicationMonitor periodically computes replication work, and a call to > BlockManager#chooseUnderReplicatedBlocks selects a given number of > under-replicated blocks, choosing blocks from the highest-priority queue > first and working down to the lowest priority queue. > In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a > source for the replication is chosen from among datanodes that have an > available copy of the block needed. This is done in > BlockManager#chooseSourceDatanode. > chooseSourceDatanode's job is to choose the datanode for replication. It > chooses a random datanode from the available datanodes that has not reached > its replication limit (preferring datanodes that are currently > decommissioning). > However, the priority queue of the block does not inform the logic. If a > datanode holds the last remaining replica of a block and has already reached > its replication limit, the node is dismissed outright and the replication is > not scheduled. > In some situations, this could lead to data loss, as the last remaining > replica could disappear if an opportunity is not taken to schedule a > replication. It would be better to waive the max replication limit in cases > of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HDFS-4270) Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit
Derek Dagit created HDFS-4270: - Summary: Replications of the highest priority should be allowed to choose a source datanode that has reached its max replication limit Key: HDFS-4270 URL: https://issues.apache.org/jira/browse/HDFS-4270 Project: Hadoop HDFS Issue Type: Bug Components: namenode Affects Versions: 0.23.5, 3.0.0 Reporter: Derek Dagit Assignee: Derek Dagit Priority: Minor Fix For: 3.0.0, 2.0.3-alpha, 0.23.6 Blocks that have been identified as under-replicated are placed on one of several priority queues. The highest priority queue is essentially reserved for situations in which only one replica of the block exists, meaning it should be replicated ASAP. The ReplicationMonitor periodically computes replication work, and a call to BlockManager#chooseUnderReplicatedBlocks selects a given number of under-replicated blocks, choosing blocks from the highest-priority queue first and working down to the lowest priority queue. In the subsequent call to BlockManager#computeReplicationWorkForBlocks, a source for the replication is chosen from among datanodes that have an available copy of the block needed. This is done in BlockManager#chooseSourceDatanode. chooseSourceDatanode's job is to choose the datanode for replication. It chooses a random datanode from the available datanodes that has not reached its replication limit (preferring datanodes that are currently decommissioning). However, the priority queue of the block does not inform the logic. If a datanode holds the last remaining replica of a block and has already reached its replication limit, the node is dismissed outright and the replication is not scheduled. In some situations, this could lead to data loss, as the last remaining replica could disappear if an opportunity is not taken to schedule a replication. It would be better to waive the max replication limit in cases of highest-priority block replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
[ https://issues.apache.org/jira/browse/HDFS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4172: -- Attachment: HDFS-4172.patch Addresses comments: removed tabs and removed unnecessary call to .toString() > namenode does not URI-encode parameters when building URI for datanode request > -- > > Key: HDFS-4172 > URL: https://issues.apache.org/jira/browse/HDFS-4172 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4172.patch > > > Param values such as > foo&bar > or > foo=bar > Are not escaped in Param.toSortedString() > When these are given as, say, token parameter values, a string like > &token=foo&bar&token=foo=bar > is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
[ https://issues.apache.org/jira/browse/HDFS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4172: -- Attachment: (was: HDFS-4172.patch) > namenode does not URI-encode parameters when building URI for datanode request > -- > > Key: HDFS-4172 > URL: https://issues.apache.org/jira/browse/HDFS-4172 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > > Param values such as > foo&bar > or > foo=bar > Are not escaped in Param.toSortedString() > When these are given as, say, token parameter values, a string like > &token=foo&bar&token=foo=bar > is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
[ https://issues.apache.org/jira/browse/HDFS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4172: -- Status: Patch Available (was: Open) > namenode does not URI-encode parameters when building URI for datanode request > -- > > Key: HDFS-4172 > URL: https://issues.apache.org/jira/browse/HDFS-4172 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4172.patch > > > Param values such as > foo&bar > or > foo=bar > Are not escaped in Param.toSortedString() > When these are given as, say, token parameter values, a string like > &token=foo&bar&token=foo=bar > is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
[ https://issues.apache.org/jira/browse/HDFS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4172: -- Attachment: HDFS-4172.patch Fixes to unit test failures. Created Param.getValueString() to properly return a String of the Param value. > namenode does not URI-encode parameters when building URI for datanode request > -- > > Key: HDFS-4172 > URL: https://issues.apache.org/jira/browse/HDFS-4172 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4172.patch > > > Param values such as > foo&bar > or > foo=bar > Are not escaped in Param.toSortedString() > When these are given as, say, token parameter values, a string like > &token=foo&bar&token=foo=bar > is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
[ https://issues.apache.org/jira/browse/HDFS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4172: -- Attachment: (was: HDFS-4172.patch) > namenode does not URI-encode parameters when building URI for datanode request > -- > > Key: HDFS-4172 > URL: https://issues.apache.org/jira/browse/HDFS-4172 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > > Param values such as > foo&bar > or > foo=bar > Are not escaped in Param.toSortedString() > When these are given as, say, token parameter values, a string like > &token=foo&bar&token=foo=bar > is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
[ https://issues.apache.org/jira/browse/HDFS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4172: -- Status: Open (was: Patch Available) Resolving issues with failed tests. > namenode does not URI-encode parameters when building URI for datanode request > -- > > Key: HDFS-4172 > URL: https://issues.apache.org/jira/browse/HDFS-4172 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > > Param values such as > foo&bar > or > foo=bar > Are not escaped in Param.toSortedString() > When these are given as, say, token parameter values, a string like > &token=foo&bar&token=foo=bar > is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
[ https://issues.apache.org/jira/browse/HDFS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4172: -- Description: Param values such as foo&bar or foo=bar Are not escaped in Param.toSortedString() When these are given as, say, token parameter values, a string like &token=foo&bar&token=foo=bar is returned. was: Param values such as foo&bar or foo=bar Are not escaped in Param.toSortedString() When these are given, a string like &renewer=rvalue&token=token&tvalue is returned. > namenode does not URI-encode parameters when building URI for datanode request > -- > > Key: HDFS-4172 > URL: https://issues.apache.org/jira/browse/HDFS-4172 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4172.patch > > > Param values such as > foo&bar > or > foo=bar > Are not escaped in Param.toSortedString() > When these are given as, say, token parameter values, a string like > &token=foo&bar&token=foo=bar > is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
[ https://issues.apache.org/jira/browse/HDFS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4172: -- Description: Param values such as foo&bar or foo=bar Are not escaped in Param.toSortedString() When these are given, a string like &renewer=rvalue&token=token&tvalue is returned. was: Param values such as foo&bar or foo=bar Are not escaped in Param.toSortedString() When these are given, a string like &renewer=renewer%3Dequal&token=token%26ampersand is returned. > namenode does not URI-encode parameters when building URI for datanode request > -- > > Key: HDFS-4172 > URL: https://issues.apache.org/jira/browse/HDFS-4172 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4172.patch > > > Param values such as > foo&bar > or > foo=bar > Are not escaped in Param.toSortedString() > When these are given, a string like > &renewer=rvalue&token=token&tvalue > is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
[ https://issues.apache.org/jira/browse/HDFS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4172: -- Attachment: HDFS-4172.patch > namenode does not URI-encode parameters when building URI for datanode request > -- > > Key: HDFS-4172 > URL: https://issues.apache.org/jira/browse/HDFS-4172 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4172.patch > > > Param values such as > foo&bar > or > foo=bar > Are not escaped in Param.toSortedString() > When these are given, a string like > &renewer=renewer%3Dequal&token=token%26ampersand > is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
[ https://issues.apache.org/jira/browse/HDFS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4172: -- Status: Patch Available (was: Open) > namenode does not URI-encode parameters when building URI for datanode request > -- > > Key: HDFS-4172 > URL: https://issues.apache.org/jira/browse/HDFS-4172 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4172.patch > > > Param values such as > foo&bar > or > foo=bar > Are not escaped in Param.toSortedString() > When these are given, a string like > &renewer=renewer%3Dequal&token=token%26ampersand > is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
[ https://issues.apache.org/jira/browse/HDFS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4172: -- Status: Open (was: Patch Available) > namenode does not URI-encode parameters when building URI for datanode request > -- > > Key: HDFS-4172 > URL: https://issues.apache.org/jira/browse/HDFS-4172 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4172.patch > > > Param values such as > foo&bar > or > foo=bar > Are not escaped in Param.toSortedString() > When these are given, a string like > &renewer=renewer%3Dequal&token=token%26ampersand > is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
[ https://issues.apache.org/jira/browse/HDFS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4172: -- Attachment: (was: HDFS-4162.patch) > namenode does not URI-encode parameters when building URI for datanode request > -- > > Key: HDFS-4172 > URL: https://issues.apache.org/jira/browse/HDFS-4172 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4172.patch > > > Param values such as > foo&bar > or > foo=bar > Are not escaped in Param.toSortedString() > When these are given, a string like > &renewer=renewer%3Dequal&token=token%26ampersand > is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
[ https://issues.apache.org/jira/browse/HDFS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4172: -- Fix Version/s: (was: 0.23.5) (was: 2.0.3-alpha) (was: 3.0.0) Target Version/s: 3.0.0, 2.0.3-alpha, 0.23.5 Status: Patch Available (was: Open) > namenode does not URI-encode parameters when building URI for datanode request > -- > > Key: HDFS-4172 > URL: https://issues.apache.org/jira/browse/HDFS-4172 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4162.patch > > > Param values such as > foo&bar > or > foo=bar > Are not escaped in Param.toSortedString() > When these are given, a string like > &renewer=renewer%3Dequal&token=token%26ampersand > is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
[ https://issues.apache.org/jira/browse/HDFS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4172: -- Attachment: HDFS-4162.patch URI-Encode the param strings when building the sorted string with UTF-8. Also added test and JavaDocs. > namenode does not URI-encode parameters when building URI for datanode request > -- > > Key: HDFS-4172 > URL: https://issues.apache.org/jira/browse/HDFS-4172 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4162.patch > > > Param values such as > foo&bar > or > foo=bar > Are not escaped in Param.toSortedString() > When these are given, a string like > &renewer=renewer%3Dequal&token=token%26ampersand > is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HDFS-4172) namenode does not URI-encode parameters when building URI for datanode request
Derek Dagit created HDFS-4172: - Summary: namenode does not URI-encode parameters when building URI for datanode request Key: HDFS-4172 URL: https://issues.apache.org/jira/browse/HDFS-4172 Project: Hadoop HDFS Issue Type: Bug Components: name-node Affects Versions: 0.23.4 Reporter: Derek Dagit Assignee: Derek Dagit Priority: Minor Fix For: 3.0.0, 2.0.3-alpha, 0.23.5 Param values such as foo&bar or foo=bar Are not escaped in Param.toSortedString() When these are given, a string like &renewer=renewer%3Dequal&token=token%26ampersand is returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4162) Some malformed and unquoted HTML strings are returned from datanode web ui
[ https://issues.apache.org/jira/browse/HDFS-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4162: -- Status: Patch Available (was: Open) Fixes formatting in new test method > Some malformed and unquoted HTML strings are returned from datanode web ui > -- > > Key: HDFS-4162 > URL: https://issues.apache.org/jira/browse/HDFS-4162 > Project: Hadoop HDFS > Issue Type: Bug > Components: data-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4162-branch-0.23.patch, HDFS-4162.patch > > > When browsing to the datanode at /browseDirectory.jsp, if a path with HTML > characters is requested, the resulting error page echos back the input > unquoted. > Example: > http://localhost:50075/browseDirectory.jsp?dir=/&go=go&namenodeInfoPort=50070&nnaddr=localhost%3A9000 > Writes an input element as part of the response: > > - The value of the "value" attribute is not quoted. > - An = must follow the "id" attribute name. > - Element "input" should have a closing tag. > The output should be something like: > > In addition, if one creates a directory: > hdfs dfs -put '/some/path/to/' > Then browsing to the parent of directory '' prints unquoted HTML in the > directory names. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4162) Some malformed and unquoted HTML strings are returned from datanode web ui
[ https://issues.apache.org/jira/browse/HDFS-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4162: -- Attachment: (was: HDFS-4162.patch) > Some malformed and unquoted HTML strings are returned from datanode web ui > -- > > Key: HDFS-4162 > URL: https://issues.apache.org/jira/browse/HDFS-4162 > Project: Hadoop HDFS > Issue Type: Bug > Components: data-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4162-branch-0.23.patch, HDFS-4162.patch > > > When browsing to the datanode at /browseDirectory.jsp, if a path with HTML > characters is requested, the resulting error page echos back the input > unquoted. > Example: > http://localhost:50075/browseDirectory.jsp?dir=/&go=go&namenodeInfoPort=50070&nnaddr=localhost%3A9000 > Writes an input element as part of the response: > > - The value of the "value" attribute is not quoted. > - An = must follow the "id" attribute name. > - Element "input" should have a closing tag. > The output should be something like: > > In addition, if one creates a directory: > hdfs dfs -put '/some/path/to/' > Then browsing to the parent of directory '' prints unquoted HTML in the > directory names. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4162) Some malformed and unquoted HTML strings are returned from datanode web ui
[ https://issues.apache.org/jira/browse/HDFS-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4162: -- Attachment: (was: HDFS-4162-branch-0.23.patch) > Some malformed and unquoted HTML strings are returned from datanode web ui > -- > > Key: HDFS-4162 > URL: https://issues.apache.org/jira/browse/HDFS-4162 > Project: Hadoop HDFS > Issue Type: Bug > Components: data-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4162-branch-0.23.patch, HDFS-4162.patch > > > When browsing to the datanode at /browseDirectory.jsp, if a path with HTML > characters is requested, the resulting error page echos back the input > unquoted. > Example: > http://localhost:50075/browseDirectory.jsp?dir=/&go=go&namenodeInfoPort=50070&nnaddr=localhost%3A9000 > Writes an input element as part of the response: > > - The value of the "value" attribute is not quoted. > - An = must follow the "id" attribute name. > - Element "input" should have a closing tag. > The output should be something like: > > In addition, if one creates a directory: > hdfs dfs -put '/some/path/to/' > Then browsing to the parent of directory '' prints unquoted HTML in the > directory names. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4162) Some malformed and unquoted HTML strings are returned from datanode web ui
[ https://issues.apache.org/jira/browse/HDFS-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4162: -- Attachment: HDFS-4162.patch > Some malformed and unquoted HTML strings are returned from datanode web ui > -- > > Key: HDFS-4162 > URL: https://issues.apache.org/jira/browse/HDFS-4162 > Project: Hadoop HDFS > Issue Type: Bug > Components: data-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4162-branch-0.23.patch, HDFS-4162.patch > > > When browsing to the datanode at /browseDirectory.jsp, if a path with HTML > characters is requested, the resulting error page echos back the input > unquoted. > Example: > http://localhost:50075/browseDirectory.jsp?dir=/&go=go&namenodeInfoPort=50070&nnaddr=localhost%3A9000 > Writes an input element as part of the response: > > - The value of the "value" attribute is not quoted. > - An = must follow the "id" attribute name. > - Element "input" should have a closing tag. > The output should be something like: > > In addition, if one creates a directory: > hdfs dfs -put '/some/path/to/' > Then browsing to the parent of directory '' prints unquoted HTML in the > directory names. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4162) Some malformed and unquoted HTML strings are returned from datanode web ui
[ https://issues.apache.org/jira/browse/HDFS-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4162: -- Attachment: HDFS-4162-branch-0.23.patch > Some malformed and unquoted HTML strings are returned from datanode web ui > -- > > Key: HDFS-4162 > URL: https://issues.apache.org/jira/browse/HDFS-4162 > Project: Hadoop HDFS > Issue Type: Bug > Components: data-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4162-branch-0.23.patch, > HDFS-4162-branch-0.23.patch, HDFS-4162.patch > > > When browsing to the datanode at /browseDirectory.jsp, if a path with HTML > characters is requested, the resulting error page echos back the input > unquoted. > Example: > http://localhost:50075/browseDirectory.jsp?dir=/&go=go&namenodeInfoPort=50070&nnaddr=localhost%3A9000 > Writes an input element as part of the response: > > - The value of the "value" attribute is not quoted. > - An = must follow the "id" attribute name. > - Element "input" should have a closing tag. > The output should be something like: > > In addition, if one creates a directory: > hdfs dfs -put '/some/path/to/' > Then browsing to the parent of directory '' prints unquoted HTML in the > directory names. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4162) Some malformed and unquoted HTML strings are returned from datanode web ui
[ https://issues.apache.org/jira/browse/HDFS-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4162: -- Status: Open (was: Patch Available) Addressing formatting comments > Some malformed and unquoted HTML strings are returned from datanode web ui > -- > > Key: HDFS-4162 > URL: https://issues.apache.org/jira/browse/HDFS-4162 > Project: Hadoop HDFS > Issue Type: Bug > Components: data-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Assignee: Derek Dagit >Priority: Minor > Attachments: HDFS-4162-branch-0.23.patch, HDFS-4162.patch > > > When browsing to the datanode at /browseDirectory.jsp, if a path with HTML > characters is requested, the resulting error page echos back the input > unquoted. > Example: > http://localhost:50075/browseDirectory.jsp?dir=/&go=go&namenodeInfoPort=50070&nnaddr=localhost%3A9000 > Writes an input element as part of the response: > > - The value of the "value" attribute is not quoted. > - An = must follow the "id" attribute name. > - Element "input" should have a closing tag. > The output should be something like: > > In addition, if one creates a directory: > hdfs dfs -put '/some/path/to/' > Then browsing to the parent of directory '' prints unquoted HTML in the > directory names. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-4162) Some malformed and unquoted HTML strings are returned from datanode web ui
[ https://issues.apache.org/jira/browse/HDFS-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492761#comment-13492761 ] Derek Dagit commented on HDFS-4162: --- Yes, please give me permission to assign this to myself. > Some malformed and unquoted HTML strings are returned from datanode web ui > -- > > Key: HDFS-4162 > URL: https://issues.apache.org/jira/browse/HDFS-4162 > Project: Hadoop HDFS > Issue Type: Bug > Components: data-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Priority: Minor > Attachments: HDFS-4162-branch-0.23.patch, HDFS-4162.patch > > > When browsing to the datanode at /browseDirectory.jsp, if a path with HTML > characters is requested, the resulting error page echos back the input > unquoted. > Example: > http://localhost:50075/browseDirectory.jsp?dir=/&go=go&namenodeInfoPort=50070&nnaddr=localhost%3A9000 > Writes an input element as part of the response: > > - The value of the "value" attribute is not quoted. > - An = must follow the "id" attribute name. > - Element "input" should have a closing tag. > The output should be something like: > > In addition, if one creates a directory: > hdfs dfs -put '/some/path/to/' > Then browsing to the parent of directory '' prints unquoted HTML in the > directory names. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4162) Some malformed and unquoted HTML strings are returned from datanode web ui
[ https://issues.apache.org/jira/browse/HDFS-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4162: -- Status: Patch Available (was: Open) > Some malformed and unquoted HTML strings are returned from datanode web ui > -- > > Key: HDFS-4162 > URL: https://issues.apache.org/jira/browse/HDFS-4162 > Project: Hadoop HDFS > Issue Type: Bug > Components: data-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Priority: Minor > Attachments: HDFS-4162-branch-0.23.patch, HDFS-4162.patch > > > When browsing to the datanode at /browseDirectory.jsp, if a path with HTML > characters is requested, the resulting error page echos back the input > unquoted. > Example: > http://localhost:50075/browseDirectory.jsp?dir=/&go=go&namenodeInfoPort=50070&nnaddr=localhost%3A9000 > Writes an input element as part of the response: > > - The value of the "value" attribute is not quoted. > - An = must follow the "id" attribute name. > - Element "input" should have a closing tag. > The output should be something like: > > In addition, if one creates a directory: > hdfs dfs -put '/some/path/to/' > Then browsing to the parent of directory '' prints unquoted HTML in the > directory names. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4162) Some malformed and unquoted HTML strings are returned from datanode web ui
[ https://issues.apache.org/jira/browse/HDFS-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4162: -- Attachment: HDFS-4162-branch-0.23.patch > Some malformed and unquoted HTML strings are returned from datanode web ui > -- > > Key: HDFS-4162 > URL: https://issues.apache.org/jira/browse/HDFS-4162 > Project: Hadoop HDFS > Issue Type: Bug > Components: data-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Priority: Minor > Attachments: HDFS-4162-branch-0.23.patch, HDFS-4162.patch > > > When browsing to the datanode at /browseDirectory.jsp, if a path with HTML > characters is requested, the resulting error page echos back the input > unquoted. > Example: > http://localhost:50075/browseDirectory.jsp?dir=/&go=go&namenodeInfoPort=50070&nnaddr=localhost%3A9000 > Writes an input element as part of the response: > > - The value of the "value" attribute is not quoted. > - An = must follow the "id" attribute name. > - Element "input" should have a closing tag. > The output should be something like: > > In addition, if one creates a directory: > hdfs dfs -put '/some/path/to/' > Then browsing to the parent of directory '' prints unquoted HTML in the > directory names. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-4162) Some malformed and unquoted HTML strings are returned from datanode web ui
[ https://issues.apache.org/jira/browse/HDFS-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Dagit updated HDFS-4162: -- Attachment: HDFS-4162.patch > Some malformed and unquoted HTML strings are returned from datanode web ui > -- > > Key: HDFS-4162 > URL: https://issues.apache.org/jira/browse/HDFS-4162 > Project: Hadoop HDFS > Issue Type: Bug > Components: data-node >Affects Versions: 0.23.4 >Reporter: Derek Dagit >Priority: Minor > Attachments: HDFS-4162-branch-0.23.patch, HDFS-4162.patch > > > When browsing to the datanode at /browseDirectory.jsp, if a path with HTML > characters is requested, the resulting error page echos back the input > unquoted. > Example: > http://localhost:50075/browseDirectory.jsp?dir=/&go=go&namenodeInfoPort=50070&nnaddr=localhost%3A9000 > Writes an input element as part of the response: > > - The value of the "value" attribute is not quoted. > - An = must follow the "id" attribute name. > - Element "input" should have a closing tag. > The output should be something like: > > In addition, if one creates a directory: > hdfs dfs -put '/some/path/to/' > Then browsing to the parent of directory '' prints unquoted HTML in the > directory names. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HDFS-4162) Some malformed and unquoted HTML strings are returned from datanode web ui
Derek Dagit created HDFS-4162: - Summary: Some malformed and unquoted HTML strings are returned from datanode web ui Key: HDFS-4162 URL: https://issues.apache.org/jira/browse/HDFS-4162 Project: Hadoop HDFS Issue Type: Bug Components: data-node Affects Versions: 0.23.4 Reporter: Derek Dagit Priority: Minor When browsing to the datanode at /browseDirectory.jsp, if a path with HTML characters is requested, the resulting error page echos back the input unquoted. Example: http://localhost:50075/browseDirectory.jsp?dir=/&go=go&namenodeInfoPort=50070&nnaddr=localhost%3A9000 Writes an input element as part of the response: - The value of the "value" attribute is not quoted. - An = must follow the "id" attribute name. - Element "input" should have a closing tag. The output should be something like: In addition, if one creates a directory: hdfs dfs -put '/some/path/to/' Then browsing to the parent of directory '' prints unquoted HTML in the directory names. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
