[jira] [Commented] (HBASE-16436) Add the CellChunkMap variant
[ https://issues.apache.org/jira/browse/HBASE-16436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607608#comment-15607608 ] ramkrishna.s.vasudevan commented on HBASE-16436: That second way of doing things will be much simpler I believe. We can have control on the whole segment with one boolean and decide. So suppose we have 3 segments and one of it has a bigger cell then I think it still makes sense to index the other two segments in the chunk way and leave the one with bigger cell to cellArray map way of indexing and things should work for scans? I need to verify this part first. > Add the CellChunkMap variant > > > Key: HBASE-16436 > URL: https://issues.apache.org/jira/browse/HBASE-16436 > Project: HBase > Issue Type: Sub-task >Reporter: ramkrishna.s.vasudevan > > This sub-task is specifically to add the CellChunkMap created by [~anastas] > and [~eshcar] with specific tests and integrate it with the in memory > flush/compaction flow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16436) Add the CellChunkMap variant
[ https://issues.apache.org/jira/browse/HBASE-16436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607579#comment-15607579 ] Anoop Sam John commented on HBASE-16436: Till it reaches the memstore add point, the big cell data is in the BB from the Rpc pool. But when we add it to memstore, we will do an on heap copy if we can not copy to MSLAB. So we are good here. Ya because of 1 big cell in 1M cells not allowing us go off heap fully is not so good :-( My feeling is that the latter will be much more simple than 1st way. Ya let us try out boths. [~ram_krish] U are ok to do this poc? No hurry. > Add the CellChunkMap variant > > > Key: HBASE-16436 > URL: https://issues.apache.org/jira/browse/HBASE-16436 > Project: HBase > Issue Type: Sub-task >Reporter: ramkrishna.s.vasudevan > > This sub-task is specifically to add the CellChunkMap created by [~anastas] > and [~eshcar] with specific tests and integrate it with the in memory > flush/compaction flow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16438) Create a cell type so that chunk id is embedded in it
[ https://issues.apache.org/jira/browse/HBASE-16438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607575#comment-15607575 ] stack commented on HBASE-16438: --- Thanks Ram. So why we write the chunkid back into the Cell? How would that help? Thanks. > Create a cell type so that chunk id is embedded in it > - > > Key: HBASE-16438 > URL: https://issues.apache.org/jira/browse/HBASE-16438 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > > For CellChunkMap we may need a cell such that the chunk out of which it was > created, the id of the chunk be embedded in it so that when doing flattening > we can use the chunk id as a meta data. More details will follow once the > initial tasks are completed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16436) Add the CellChunkMap variant
[ https://issues.apache.org/jira/browse/HBASE-16436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607562#comment-15607562 ] stack commented on HBASE-16436: --- [~anoop.hbase] Thanks for the better explanation. Will the too-big Cell be occupying a BB from the RPC Pool preventing our releasing it? Or will it have already have been allocated on the heap? If the latter good. We just need a hash of fake chunkid to this Cell on-heap. Ok if the fake chunk id solves two problems. Yes to both ways. On latter, would be a shame if we couldn't go offheap because 1 in 10M Cells is bigger than a SLAB. > Add the CellChunkMap variant > > > Key: HBASE-16436 > URL: https://issues.apache.org/jira/browse/HBASE-16436 > Project: HBase > Issue Type: Sub-task >Reporter: ramkrishna.s.vasudevan > > This sub-task is specifically to add the CellChunkMap created by [~anastas] > and [~eshcar] with specific tests and integrate it with the in memory > flush/compaction flow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607532#comment-15607532 ] stack commented on HBASE-16890: --- Let me try the sloppy way first. Maybe the synchronizes are not the problem [~ram_krish] > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: Screen Shot 2016-10-25 at 7.34.47 PM.png, Screen Shot > 2016-10-25 at 7.39.07 PM.png, Screen Shot 2016-10-25 at 7.39.48 PM.png, > async.svg, classic.svg, contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607512#comment-15607512 ] ramkrishna.s.vasudevan commented on HBASE-16890: [~saint@gmail.com] Can I check the disruptor way to reduce synchronization overhead? If am not able to get to it I shall tell you. Just telling before you put in your time in that? > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: Screen Shot 2016-10-25 at 7.34.47 PM.png, Screen Shot > 2016-10-25 at 7.39.07 PM.png, Screen Shot 2016-10-25 at 7.39.48 PM.png, > async.svg, classic.svg, contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16438) Create a cell type so that chunk id is embedded in it
[ https://issues.apache.org/jira/browse/HBASE-16438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607511#comment-15607511 ] Anoop Sam John commented on HBASE-16438: In CellChunkMap, we will get rid of Cell objects and will keep only some index data. So this index data has to tell us in which byte[]/BB/Chunk the cell data resides and in which offset and what is its total length. The latter 2 are ints. The 1st one is a pointer. Again we will need to keep it on heap. Where what the solution proposes is to keep an id of the chunk where this cell resides instead of keeping a java ref to this chunk object. That is why the chunk id is imp now. Now normal cells will have only ref to chunks. So when an in memory flush happens and we make the chunk map, we dont know the index/id of this chunk. That is why we were saying that we can keep the chunk id int within the cell object. > Create a cell type so that chunk id is embedded in it > - > > Key: HBASE-16438 > URL: https://issues.apache.org/jira/browse/HBASE-16438 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > > For CellChunkMap we may need a cell such that the chunk out of which it was > created, the id of the chunk be embedded in it so that when doing flattening > we can use the chunk id as a meta data. More details will follow once the > initial tasks are completed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607505#comment-15607505 ] stack commented on HBASE-16890: --- Let me try a [~Apache9] suggestion of a version that is sloppy synchronizing and see if we get the expected speedup. I'll be back. > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: Screen Shot 2016-10-25 at 7.34.47 PM.png, Screen Shot > 2016-10-25 at 7.39.07 PM.png, Screen Shot 2016-10-25 at 7.39.48 PM.png, > async.svg, classic.svg, contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16436) Add the CellChunkMap variant
[ https://issues.apache.org/jira/browse/HBASE-16436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607503#comment-15607503 ] Anoop Sam John commented on HBASE-16436: You mean to say when the cell size does not allow it to be copied to an MSLAB chunk (from pool) let us have the cell be there as such (we will copy the data then as till it reaches memstore level, the cells data is backed by the same byte[] where the RPCServer copied the req bytes into) and that cell's backing buffer we will make as a fake chunk? We will keep it temp with a temp chunk id and once the life of the cell is over, flushed, we will throw away that chunk? Hmm seems some thing we can try out. MSLAB pool default ON am not sure whether that jira got committed already. Ya we can do. There is one more issue. [~ram_krish] reminded me some days back. When a cell is upserted (append/increment op), we will not copy that cell to MSLAB. So in such a case also we may need to go with this way of temp chunks with temp ids. Another idea I can think of is as follows Let us keep the info that whether a Segment contains a cell which is not copied to MSLAB. A boolean like 'tagsPresent'. When we do in memory flush we will do CellArrayMap if any of the cell is NOT in MSLAB. If all in MSLAB, we will do chunk map. Also when an in memory merge or data compaction happens, then also similar way. When any of the segment undergoing merge is having a cell not in MSLAB, lets go with cell array map instead of cell chunkmap. May be we need some logic there where we can avoid segments with cells not in MSLAB from getting merged with segmnets whose all cells in MSALB only. Chance is that when a segment is having cells not in MSLAB, other segments also will follow same pattern (99% I can say).. Need evaluation of both ways anyway. Just some thoughts > Add the CellChunkMap variant > > > Key: HBASE-16436 > URL: https://issues.apache.org/jira/browse/HBASE-16436 > Project: HBase > Issue Type: Sub-task >Reporter: ramkrishna.s.vasudevan > > This sub-task is specifically to add the CellChunkMap created by [~anastas] > and [~eshcar] with specific tests and integrate it with the in memory > flush/compaction flow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16438) Create a cell type so that chunk id is embedded in it
[ https://issues.apache.org/jira/browse/HBASE-16438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607499#comment-15607499 ] ramkrishna.s.vasudevan commented on HBASE-16438: Thanks for your comments. The case I think of is this. We do in memory flushes now. So every in memory flush will create a segment. The cells are located in this segment. When MSLAB is ON and chunk pool is ON we create a chunk from the pool and that is where the cells are added. Now this segment is of type CSLM each entry pointing to the chunk created from the chunk pool. When I try to create an index out of this I don't add the chunk where the cell is added. Instead I just add the chunkid (assume when we ask for a chunk from the pool it gives out an id) and the cell's offset and length. Why chunk id is important is because again say there is one more in memory flush and we create one more segment and the old one is pushed to the pipeline. So we convert this segment from CSLM to chunk based. Now in my index array since I have another segment added I need to clearly know for which segment was this chunk created because the cell's offset and length could be same and there is no unique way to distinguish. In the CellArrayMap impl there is no such need because just that they create an array of cells and every index in the array points to the cell referenced inside the chunks. We don't need any chunkid there. Because it points to actual cells. But in CellChunkIndex we don't point to actual cells. Let me know if I am writing it clearly if not can rephrase again. Thanks. > Create a cell type so that chunk id is embedded in it > - > > Key: HBASE-16438 > URL: https://issues.apache.org/jira/browse/HBASE-16438 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > > For CellChunkMap we may need a cell such that the chunk out of which it was > created, the id of the chunk be embedded in it so that when doing flattening > we can use the chunk id as a meta data. More details will follow once the > initial tasks are completed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16932) Implement small scan
[ https://issues.apache.org/jira/browse/HBASE-16932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-16932: -- Attachment: HBASE-16932-v1.patch Missed the new UT. > Implement small scan > > > Key: HBASE-16932 > URL: https://issues.apache.org/jira/browse/HBASE-16932 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-16932-v1.patch, HBASE-16932.patch > > > As said in HBASE-16838, we should have a scan method that returns a > CompletaFuture for the whole result. It is suitable for a small scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16783) Use ByteBufferPool for the header and message during Rpc response
[ https://issues.apache.org/jira/browse/HBASE-16783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-16783: --- Attachment: HBASE-16783_7.patch REtry QA. > Use ByteBufferPool for the header and message during Rpc response > - > > Key: HBASE-16783 > URL: https://issues.apache.org/jira/browse/HBASE-16783 > Project: HBase > Issue Type: Improvement >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Attachments: HBASE-16783.patch, HBASE-16783_1.patch, > HBASE-16783_2.patch, HBASE-16783_3.patch, HBASE-16783_4.patch, > HBASE-16783_5.patch, HBASE-16783_6.patch, HBASE-16783_7.patch, > HBASE-16783_7.patch > > > With ByteBufferPool in place we could avoid the byte[] creation in > RpcServer#createHeaderAndMessageBytes and try using the Buffer from the pool > rather than creating byte[] every time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16783) Use ByteBufferPool for the header and message during Rpc response
[ https://issues.apache.org/jira/browse/HBASE-16783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-16783: --- Status: Patch Available (was: Open) > Use ByteBufferPool for the header and message during Rpc response > - > > Key: HBASE-16783 > URL: https://issues.apache.org/jira/browse/HBASE-16783 > Project: HBase > Issue Type: Improvement >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Attachments: HBASE-16783.patch, HBASE-16783_1.patch, > HBASE-16783_2.patch, HBASE-16783_3.patch, HBASE-16783_4.patch, > HBASE-16783_5.patch, HBASE-16783_6.patch, HBASE-16783_7.patch, > HBASE-16783_7.patch > > > With ByteBufferPool in place we could avoid the byte[] creation in > RpcServer#createHeaderAndMessageBytes and try using the Buffer from the pool > rather than creating byte[] every time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16783) Use ByteBufferPool for the header and message during Rpc response
[ https://issues.apache.org/jira/browse/HBASE-16783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-16783: --- Status: Open (was: Patch Available) > Use ByteBufferPool for the header and message during Rpc response > - > > Key: HBASE-16783 > URL: https://issues.apache.org/jira/browse/HBASE-16783 > Project: HBase > Issue Type: Improvement >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Attachments: HBASE-16783.patch, HBASE-16783_1.patch, > HBASE-16783_2.patch, HBASE-16783_3.patch, HBASE-16783_4.patch, > HBASE-16783_5.patch, HBASE-16783_6.patch, HBASE-16783_7.patch, > HBASE-16783_7.patch > > > With ByteBufferPool in place we could avoid the byte[] creation in > RpcServer#createHeaderAndMessageBytes and try using the Buffer from the pool > rather than creating byte[] every time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16932) Implement small scan
[ https://issues.apache.org/jira/browse/HBASE-16932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-16932: -- Attachment: (was: HBASE-16932-v1.patch) > Implement small scan > > > Key: HBASE-16932 > URL: https://issues.apache.org/jira/browse/HBASE-16932 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-16932.patch > > > As said in HBASE-16838, we should have a scan method that returns a > CompletaFuture for the whole result. It is suitable for a small scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607473#comment-15607473 ] ramkrishna.s.vasudevan commented on HBASE-16890: bq.The disruptor consumer thread would feed the eventloop? Could. Another thought was just collect the appends and not assign the trans id until we are going to sync since that is when we add the edit to the WAL and given that the write path is different in master – we don't update memstore until after sync has come home – then this could work. For doing the second one then it means we can't create a FSWALEntry till we do the sync and we need to carry the edits upto the sync part. The first one I think is doable. As I said since we don't go with disruptor we need a sequence generator and since 'waitingConsumePayloads' acts as the critical section for the consumer - we need to do a sync for getting unique txids. Now may be we can add a disruptor and onEvent of the disruptor we can hand over to the eventLoop? But there is context switch here and one thread handing over to the other. I can work on these two. So we can first check the disruptor way or the append way? Thanks Stack for your tests. Even myy JFR report had the contention issue but I felt that sync and CRC update was *also* taking more time than the FSHLog (classic) case. > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: Screen Shot 2016-10-25 at 7.34.47 PM.png, Screen Shot > 2016-10-25 at 7.39.07 PM.png, Screen Shot 2016-10-25 at 7.39.48 PM.png, > async.svg, classic.svg, contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16932) Implement small scan
[ https://issues.apache.org/jira/browse/HBASE-16932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-16932: -- Attachment: HBASE-16932-v1.patch Fix the javadoc and findbugs warnings. > Implement small scan > > > Key: HBASE-16932 > URL: https://issues.apache.org/jira/browse/HBASE-16932 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-16932-v1.patch, HBASE-16932.patch > > > As said in HBASE-16838, we should have a scan method that returns a > CompletaFuture for the whole result. It is suitable for a small scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-13272) Get.setClosestRowBefore() breaks specific column Get
[ https://issues.apache.org/jira/browse/HBASE-13272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-13272. --- Resolution: Won't Fix getClosestRowOrBefore got removed by HBASE-13954 after @deprecation cycle. > Get.setClosestRowBefore() breaks specific column Get > > > Key: HBASE-13272 > URL: https://issues.apache.org/jira/browse/HBASE-13272 > Project: HBase > Issue Type: Bug >Reporter: stack >Priority: Trivial > > Via [~larsgeorge] > Get.setClosestRowBefore() is breaking a specific Get that specifies a column. > If you set the latter to "true" it will return the _entire_ row! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16436) Add the CellChunkMap variant
[ https://issues.apache.org/jira/browse/HBASE-16436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607391#comment-15607391 ] stack commented on HBASE-16436: --- Hard question by [~anoop.hbase] ported from HBASE-16421 bq. The CellChunkMap variant needs cell data to be available in MSLAB chunks. So when MSLAB is OFF, we will not be using this. What abt the size restriction? In MSLAB there is a max size for Cells and above which cells will not be cloned. We might nor be able to handle such a case. Thoughts? MSLAB is on always in master branch, right? If not, lets make it so by fiat in 2.0. On size restrtiction, current default for mslab is 2MB. Seems small. For smallest possible Cell (32bytes?), thats 1M Cells. Not that much, especially when we are not looking them up via CSLS but via a nice flat index. Go to 8MB slabs? 16M? If someone wants to write a 64M Cell into HBase, should we even let them? It is going to mess us (GC, etc.) up. We have a bound on max size currently. Reexamine? What is the lifecycle of a SLAB? Can we set aside negative chunkids to mean onheap and these chunks would have one object in them only? (Might have to have a globally accessible means of mapping negative chunkid to an object). > Add the CellChunkMap variant > > > Key: HBASE-16436 > URL: https://issues.apache.org/jira/browse/HBASE-16436 > Project: HBase > Issue Type: Sub-task >Reporter: ramkrishna.s.vasudevan > > This sub-task is specifically to add the CellChunkMap created by [~anastas] > and [~eshcar] with specific tests and integrate it with the in memory > flush/compaction flow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16438) Create a cell type so that chunk id is embedded in it
[ https://issues.apache.org/jira/browse/HBASE-16438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607377#comment-15607377 ] stack commented on HBASE-16438: --- I don't see where you say above why we need to write into the cell the chunkid it is associate with? Why do we have to? The index will have the chunk to find a Cell in. The Cell will not move, not unless we do a data merge. Then, a new index will be made to go with the new merged chunk. This index will point to the new location. At what point do we ever have to write the chunk id into the Cell? Thanks Ram. > Create a cell type so that chunk id is embedded in it > - > > Key: HBASE-16438 > URL: https://issues.apache.org/jira/browse/HBASE-16438 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > > For CellChunkMap we may need a cell such that the chunk out of which it was > created, the id of the chunk be embedded in it so that when doing flattening > we can use the chunk id as a meta data. More details will follow once the > initial tasks are completed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16944) Fix findbugs warning in hbase-server HRegion UL_UNRELEASED_LOCK
[ https://issues.apache.org/jira/browse/HBASE-16944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607352#comment-15607352 ] Hudson commented on HBASE-16944: SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #1855 (See [https://builds.apache.org/job/HBase-Trunk_matrix/1855/]) HBASE-16944 Fix findbugs warning in hbase-server HRegion (stack: rev bbe88d942ec4ac673cdaf266d4bf7e15d2b334d8) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java > Fix findbugs warning in hbase-server HRegion UL_UNRELEASED_LOCK > --- > > Key: HBASE-16944 > URL: https://issues.apache.org/jira/browse/HBASE-16944 > Project: HBase > Issue Type: Bug > Components: findbugs >Reporter: stack > > Fix the annoying long-lived UL_UNRELEASED_LOCK warning out of line 3251 in > HRegion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16421) Introducing the CellChunkMap as a new additional index variant in the MemStore
[ https://issues.apache.org/jira/browse/HBASE-16421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607350#comment-15607350 ] stack commented on HBASE-16421: --- Copied this, the question we need to answer, over to HBASE-16436 > Introducing the CellChunkMap as a new additional index variant in the MemStore > -- > > Key: HBASE-16421 > URL: https://issues.apache.org/jira/browse/HBASE-16421 > Project: HBase > Issue Type: Umbrella >Reporter: Anastasia Braginsky > > Follow up for HBASE-14921. This is going to be the umbrella JIRA to include > all the parts of integration of the CellChunkMap to the MemStore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16000) Table#checkAndPut() docs are too vague
[
https://issues.apache.org/jira/browse/HBASE-16000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607348#comment-15607348
]
Hudson commented on HBASE-16000:
SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #1855 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/1855/])
HBASE-16000 Table#checkAndPut() docs are too vague (Csaba Skrabak) This (stack:
rev 8e2d410195b1797e2d7e647db431e4fde98aeaba)
* (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Table.java
> Table#checkAndPut() docs are too vague
> --
>
> Key: HBASE-16000
> URL: https://issues.apache.org/jira/browse/HBASE-16000
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Nick Dimiduk
>Assignee: Csaba Skrabak
>Priority: Minor
> Labels: beginner, beginners
> Fix For: 2.0.0
>
> Attachments: hbase-16000.patch
>
>
> The docs for our CAS operations that accept a {{CompareOp}} are too vague.
> They're copied from the part that implies {{CompareOp.EQUAL}}, which means
> they don't tell you how your op, the provided {{value}}, and any present
> value are compared.
> Only by digging into HRegion.java can I see that the operation is, for
> example with CompareOp.GREATER, we get {{value.compareTo(existingKeyValue) >
> 0}}. Javadocs should be explicit about the order of operands.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-1600) Multiple HBase clients to multiple indpendent HBase clusters from the same jvm should be allowed
[ https://issues.apache.org/jira/browse/HBASE-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607351#comment-15607351 ] Hudson commented on HBASE-1600: --- SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #1855 (See [https://builds.apache.org/job/HBase-Trunk_matrix/1855/]) Revert "HBASE-1600 Table#checkAndPut() docs are too vague (Csaba (stack: rev 9c6d123b224f63d8456680dcc5c701d04954634e) * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Table.java HBASE-16000 Table#checkAndPut() docs are too vague (Csaba Skrabak) This (stack: rev 8e2d410195b1797e2d7e647db431e4fde98aeaba) * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Table.java > Multiple HBase clients to multiple indpendent HBase clusters from the same > jvm should be allowed > > > Key: HBASE-1600 > URL: https://issues.apache.org/jira/browse/HBASE-1600 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.20.0 >Reporter: Chris K Wensel >Assignee: Nitay Joffe >Priority: Blocker > > ZK quorum servers list is static in ZooKeeperWrapper and is coupled to > zoo.cfg. > This prevents multiple clients from connecting to multiple distinct HBase > clusters and requires zoo.cfg to exist on a cluster that needs to connect to > a remote HBase cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16932) Implement small scan
[ https://issues.apache.org/jira/browse/HBASE-16932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607322#comment-15607322 ] stack commented on HBASE-16932: --- [~Apache9] This just went in and should fix the old findbugs issue: commit bbe88d942ec4ac673cdaf266d4bf7e15d2b334d8 Author: Michael Stack Date: Tue Oct 25 14:44:11 2016 -0700 HBASE-16944 Fix findbugs warning in hbase-server HRegion UL_UNRELEASED_LOCK > Implement small scan > > > Key: HBASE-16932 > URL: https://issues.apache.org/jira/browse/HBASE-16932 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-16932.patch > > > As said in HBASE-16838, we should have a scan method that returns a > CompletaFuture for the whole result. It is suitable for a small scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16944) Fix findbugs warning in hbase-server HRegion UL_UNRELEASED_LOCK
[ https://issues.apache.org/jira/browse/HBASE-16944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607281#comment-15607281 ] Yu Li commented on HBASE-16944: --- Thanks for fixing this sir [~stack] > Fix findbugs warning in hbase-server HRegion UL_UNRELEASED_LOCK > --- > > Key: HBASE-16944 > URL: https://issues.apache.org/jira/browse/HBASE-16944 > Project: HBase > Issue Type: Bug > Components: findbugs >Reporter: stack > > Fix the annoying long-lived UL_UNRELEASED_LOCK warning out of line 3251 in > HRegion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16931) Setting cell's seqId to zero in compaction flow might cause RS down.
[
https://issues.apache.org/jira/browse/HBASE-16931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607278#comment-15607278
]
Yu Li commented on HBASE-16931:
---
Skimmed log of failed post-commit check for trunk/branch-1/branch-1.1 and
confirmed all caused by known fake case or timed out, no regression caused by
change here, FWIW.
> Setting cell's seqId to zero in compaction flow might cause RS down.
>
>
> Key: HBASE-16931
> URL: https://issues.apache.org/jira/browse/HBASE-16931
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: binlijin
>Assignee: binlijin
>Priority: Critical
> Fix For: 2.0.0, 1.4.0, 1.2.4, 1.1.8
>
> Attachments: HBASE-16931-master.patch, HBASE-16931.branch-1.patch,
> HBASE-16931.branch-1.v2.patch, HBASE-16931_master_v2.patch,
> HBASE-16931_master_v3.patch, HBASE-16931_master_v4.patch,
> HBASE-16931_master_v5.patch
>
>
> Compactor#performCompaction
> do {
> hasMore = scanner.next(cells, scannerContext);
> // output to writer:
> for (Cell c : cells) {
> if (cleanSeqId && c.getSequenceId() <= smallestReadPoint) {
> CellUtil.setSequenceId(c, 0);
> }
> writer.append(c);
> }
> cells.clear();
> } while (hasMore);
> scanner.next will choose at most "hbase.hstore.compaction.kv.max" kvs, the
> last cell still reference by StoreScanner.prevCell, so if cleanSeqId is
> called when the scanner.next call StoreScanner.checkScanOrder may throw
> exception and cause regionserver down.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16931) Setting cell's seqId to zero in compaction flow might cause RS down.
[
https://issues.apache.org/jira/browse/HBASE-16931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607269#comment-15607269
]
Yu Li commented on HBASE-16931:
---
bq. The choice is between this going into 1.3.0 or waiting for 1.3.1, right?
Yes sir. [~busbey]
> Setting cell's seqId to zero in compaction flow might cause RS down.
>
>
> Key: HBASE-16931
> URL: https://issues.apache.org/jira/browse/HBASE-16931
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: binlijin
>Assignee: binlijin
>Priority: Critical
> Fix For: 2.0.0, 1.4.0, 1.2.4, 1.1.8
>
> Attachments: HBASE-16931-master.patch, HBASE-16931.branch-1.patch,
> HBASE-16931.branch-1.v2.patch, HBASE-16931_master_v2.patch,
> HBASE-16931_master_v3.patch, HBASE-16931_master_v4.patch,
> HBASE-16931_master_v5.patch
>
>
> Compactor#performCompaction
> do {
> hasMore = scanner.next(cells, scannerContext);
> // output to writer:
> for (Cell c : cells) {
> if (cleanSeqId && c.getSequenceId() <= smallestReadPoint) {
> CellUtil.setSequenceId(c, 0);
> }
> writer.append(c);
> }
> cells.clear();
> } while (hasMore);
> scanner.next will choose at most "hbase.hstore.compaction.kv.max" kvs, the
> last cell still reference by StoreScanner.prevCell, so if cleanSeqId is
> called when the scanner.next call StoreScanner.checkScanOrder may throw
> exception and cause regionserver down.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16932) Implement small scan
[ https://issues.apache.org/jira/browse/HBASE-16932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607262#comment-15607262 ] Duo Zhang commented on HBASE-16932: --- Let me fix the findbugs and javadoc warnings and try precommit again. > Implement small scan > > > Key: HBASE-16932 > URL: https://issues.apache.org/jira/browse/HBASE-16932 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-16932.patch > > > As said in HBASE-16838, we should have a scan method that returns a > CompletaFuture for the whole result. It is suitable for a small scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16932) Implement small scan
[ https://issues.apache.org/jira/browse/HBASE-16932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607256#comment-15607256 ] Yu Li commented on HBASE-16932: --- +1, makes sense to have a new "smallScan" API for async call, and current API lgtm. Thanks. > Implement small scan > > > Key: HBASE-16932 > URL: https://issues.apache.org/jira/browse/HBASE-16932 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-16932.patch > > > As said in HBASE-16838, we should have a scan method that returns a > CompletaFuture for the whole result. It is suitable for a small scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607210#comment-15607210 ] Duo Zhang commented on HBASE-16890: --- I think consume method does the main work here so it is reasonable that it spent lots of cpu time. And the contention, maybe I could use the RingBuffer of Disruptor to reduce the time spent in critical section. Will try later. > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: Screen Shot 2016-10-25 at 7.34.47 PM.png, Screen Shot > 2016-10-25 at 7.39.07 PM.png, Screen Shot 2016-10-25 at 7.39.48 PM.png, > async.svg, classic.svg, contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16886) hbase-client: scanner with reversed=true and small=true gets no result
[ https://issues.apache.org/jira/browse/HBASE-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-16886: --- Affects Version/s: 1.4.0 1.3.0 2.0.0 1.2.3 1.1.7 0.98.23 > hbase-client: scanner with reversed=true and small=true gets no result > -- > > Key: HBASE-16886 > URL: https://issues.apache.org/jira/browse/HBASE-16886 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.2.3, 1.1.7, 0.98.23 >Reporter: huzheng > Labels: patch > Attachments: HBASE-16886.v0.patch, HBASE-16886.v1.patch, > HBASE-16886.v2.patch, HBASE-16886.v3.patch, TestReversedSmallScan.java > > > Assume HBase have four regions (-oo, b), [b, c), [c, d), [d,+oo) , and all > rowKeys are located in region [d, +oo). using a Reversed Small Scanner will > get no result. > Attached file show this failed test case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607175#comment-15607175 ] stack commented on HBASE-16890: --- I can spend some time on this if you want. Just say. > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: Screen Shot 2016-10-25 at 7.34.47 PM.png, Screen Shot > 2016-10-25 at 7.39.07 PM.png, Screen Shot 2016-10-25 at 7.39.48 PM.png, > async.svg, classic.svg, contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-16890: -- Attachment: Screen Shot 2016-10-25 at 7.39.48 PM.png Screen Shot 2016-10-25 at 7.39.07 PM.png Screen Shot 2016-10-25 at 7.34.47 PM.png classic.svg async.svg Here are some flame graphs of classic vs async. We are in consume a good while of the cpu spent. Screenshot shows call tree in JFR for same async.svg period. These are time spent when sampling. Hard to get a good handle on synchronize/lock friction. One view is if an item shows up frequently in the thread contention view. Again we are sampling so if it shows here my thinking is that it must be a pain point (JFR does the unsafe safe point sampling so its view is a bit closer to what is going on). I include two images from same jfr compares of the contention windows for async and classic. > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: Screen Shot 2016-10-25 at 7.34.47 PM.png, Screen Shot > 2016-10-25 at 7.39.07 PM.png, Screen Shot 2016-10-25 at 7.39.48 PM.png, > async.svg, classic.svg, contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15748) Don't link in static libunwind.
[ https://issues.apache.org/jira/browse/HBASE-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607120#comment-15607120 ] Hudson commented on HBASE-15748: SUCCESS: Integrated in Jenkins build HBase-1.2-JDK7 #56 (See [https://builds.apache.org/job/HBase-1.2-JDK7/56/]) HBASE-15748 update CHANGES.txt for additional changes in RC1. (busbey: rev 67592f3d062743907f8c5ae00dbbe1ae4f69e5af) * (edit) CHANGES.txt > Don't link in static libunwind. > --- > > Key: HBASE-15748 > URL: https://issues.apache.org/jira/browse/HBASE-15748 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-15748.patch > > > A static libunwind compiled with gcc prevents clang from catching exceptions. > So just add the dynamic one. :-/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16939) ExportSnapshot: set owner and permission on right directory
[
https://issues.apache.org/jira/browse/HBASE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607118#comment-15607118
]
Hudson commented on HBASE-16939:
SUCCESS: Integrated in Jenkins build HBase-1.2-JDK7 #56 (See
[https://builds.apache.org/job/HBase-1.2-JDK7/56/])
HBASE-16939 ExportSnapshot: set owner and permission on right directory
(matteo.bertozzi: rev 6542d651bf4c612f9e1e7b328dbea07eca1a5ae0)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/ExportSnapshot.java
> ExportSnapshot: set owner and permission on right directory
> ---
>
> Key: HBASE-16939
> URL: https://issues.apache.org/jira/browse/HBASE-16939
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.4, 1.1.8
>
> Attachments: HBASE-16939-v1.patch, HBASE-16939.patch
>
>
> {code}
> FileUtil.copy(inputFs, snapshotDir, outputFs, initialOutputSnapshotDir,
> false, false, conf);
> if (filesUser != null || filesGroup != null) {
> setOwner(outputFs, snapshotTmpDir, filesUser, filesGroup, true);
> }
> if (filesMode > 0) {
> setPermission(outputFs, snapshotTmpDir, (short)filesMode, true);
> }
> {code}
> It copy snapshot manifest to initialOutputSnapshotDir, but it set owner on
> snapshotTmpDir. They are different directory when skipTmp is true.
> Another problem is new cluster doesn't have .hbase-snapshot directory. So
> after export snapshot, it should set owner on .hbase-snapshot directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16112) TestFlushSnapshotFromClient and TestMobFlushSnapshotFromClient are flaky
[
https://issues.apache.org/jira/browse/HBASE-16112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607100#comment-15607100
]
Jingcheng Du commented on HBASE-16112:
--
Thanks a lot [~tedyu].
HBASE-16841 can fix issues in mob snapshot (I guess part of the failures in
TestMobFlushSnapshotFromClient should be related with this). But I am not sure
if the failures in TestFlushSnapshotFromClient is caused by this. Let's see if
there are still flaky failures after HBASE-16841 is committed.
> TestFlushSnapshotFromClient and TestMobFlushSnapshotFromClient are flaky
>
>
> Key: HBASE-16112
> URL: https://issues.apache.org/jira/browse/HBASE-16112
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Jingcheng Du
>Priority: Minor
> Attachments: TestFlushSnapshotFromClient-2353.out,
> TestMobFlushSnapshotFromClient-2353.out, testSnapshotStateAfterMerge-2353.out
>
>
> On recent QA runs, TestMobFlushSnapshotFromClient failed twice.
> https://builds.apache.org/job/PreCommit-HBASE-Build/2360/#showFailuresLink
> https://builds.apache.org/job/PreCommit-HBASE-Build/2353/artifact/patchprocess/patch-unit-hbase-server.txt
> {code}
> org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient.org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient
> Run 1:
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.tearDown:123->Object.wait:-2
> » TestTimedOut
> Run 2:
> TestMobFlushSnapshotFromClient.org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient
> »
> org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient.testSnapshotStateAfterMerge(org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient)
> Run 1:
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.testSnapshotStateAfterMerge:335->TestFlushSnapshotFromClient.waitRegionsAfterMerge:526
> » RetriesExhausted
> Run 2:
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.tearDown:123 »
> InterruptedIO
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16939) ExportSnapshot: set owner and permission on right directory
[
https://issues.apache.org/jira/browse/HBASE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607101#comment-15607101
]
Hudson commented on HBASE-16939:
FAILURE: Integrated in Jenkins build HBase-1.4 #496 (See
[https://builds.apache.org/job/HBase-1.4/496/])
HBASE-16939 ExportSnapshot: set owner and permission on right directory
(matteo.bertozzi: rev 4edd8a63d2afa57a1c7029b2d6badeede8855097)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/ExportSnapshot.java
> ExportSnapshot: set owner and permission on right directory
> ---
>
> Key: HBASE-16939
> URL: https://issues.apache.org/jira/browse/HBASE-16939
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.4, 1.1.8
>
> Attachments: HBASE-16939-v1.patch, HBASE-16939.patch
>
>
> {code}
> FileUtil.copy(inputFs, snapshotDir, outputFs, initialOutputSnapshotDir,
> false, false, conf);
> if (filesUser != null || filesGroup != null) {
> setOwner(outputFs, snapshotTmpDir, filesUser, filesGroup, true);
> }
> if (filesMode > 0) {
> setPermission(outputFs, snapshotTmpDir, (short)filesMode, true);
> }
> {code}
> It copy snapshot manifest to initialOutputSnapshotDir, but it set owner on
> snapshotTmpDir. They are different directory when skipTmp is true.
> Another problem is new cluster doesn't have .hbase-snapshot directory. So
> after export snapshot, it should set owner on .hbase-snapshot directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16841) Data loss in MOB files after cloning a snapshot and deleting that snapshot
[
https://issues.apache.org/jira/browse/HBASE-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607082#comment-15607082
]
Jingcheng Du commented on HBASE-16841:
--
Thanks a lot [~stack]. I'll wait for his response.
> Data loss in MOB files after cloning a snapshot and deleting that snapshot
> --
>
> Key: HBASE-16841
> URL: https://issues.apache.org/jira/browse/HBASE-16841
> Project: HBase
> Issue Type: Bug
> Components: mob, snapshots
>Reporter: Jingcheng Du
>Assignee: Jingcheng Du
> Attachments: HBASE-16841-V2.patch, HBASE-16841-V3.patch,
> HBASE-16841.patch
>
>
> Running the following steps will probably lose MOB data when working with
> snapshots.
> 1. Create a mob-enabled table by running create 't1', {NAME => 'f1', IS_MOB
> => true, MOB_THRESHOLD => 0}.
> 2. Put millions of data.
> 3. Run {{snapshot 't1','t1_snapshot'}} to take a snapshot for this table t1.
> 4. Run {{clone_snapshot 't1_snapshot','t1_cloned'}} to clone this snapshot.
> 5. Run {{delete_snapshot 't1_snapshot'}} to delete this snapshot.
> 6. Run {{disable 't1'}} and {{delete 't1'}} to delete the table.
> 7. Now go to the archive directory of t1, the number of .link directories is
> different from the number of hfiles which means some data will be lost after
> the hfile cleaner runs.
> This is because, when taking a snapshot on a enabled mob table, each region
> flushes itself and takes a snapshot, and the mob snapshot is taken only if
> the current region is first region of the table. At that time, the flushing
> of some regions might not be finished, and some mob files are not flushed to
> disk yet. Eventually some mob files are not recorded in the snapshot manifest.
> To solve this, we need to take the mob snapshot at last after the snapshots
> on all the online and offline regions are finished in
> {{EnabledTableSnapshotHandler}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607074#comment-15607074 ] Duo Zhang commented on HBASE-16890: --- And could JFR print out the time spent in the critical section for each thread? I wonder the problem is the consumer thread does too much work under the protection of waitingConsumePayloads. > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15748) Don't link in static libunwind.
[ https://issues.apache.org/jira/browse/HBASE-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607021#comment-15607021 ] Hudson commented on HBASE-15748: SUCCESS: Integrated in Jenkins build HBase-1.2-JDK8 #51 (See [https://builds.apache.org/job/HBase-1.2-JDK8/51/]) HBASE-15748 update CHANGES.txt for additional changes in RC1. (busbey: rev 67592f3d062743907f8c5ae00dbbe1ae4f69e5af) * (edit) CHANGES.txt > Don't link in static libunwind. > --- > > Key: HBASE-15748 > URL: https://issues.apache.org/jira/browse/HBASE-15748 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-15748.patch > > > A static libunwind compiled with gcc prevents clang from catching exceptions. > So just add the dynamic one. :-/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16939) ExportSnapshot: set owner and permission on right directory
[
https://issues.apache.org/jira/browse/HBASE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607019#comment-15607019
]
Hudson commented on HBASE-16939:
SUCCESS: Integrated in Jenkins build HBase-1.2-JDK8 #51 (See
[https://builds.apache.org/job/HBase-1.2-JDK8/51/])
HBASE-16939 ExportSnapshot: set owner and permission on right directory
(matteo.bertozzi: rev 6542d651bf4c612f9e1e7b328dbea07eca1a5ae0)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/ExportSnapshot.java
> ExportSnapshot: set owner and permission on right directory
> ---
>
> Key: HBASE-16939
> URL: https://issues.apache.org/jira/browse/HBASE-16939
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.4, 1.1.8
>
> Attachments: HBASE-16939-v1.patch, HBASE-16939.patch
>
>
> {code}
> FileUtil.copy(inputFs, snapshotDir, outputFs, initialOutputSnapshotDir,
> false, false, conf);
> if (filesUser != null || filesGroup != null) {
> setOwner(outputFs, snapshotTmpDir, filesUser, filesGroup, true);
> }
> if (filesMode > 0) {
> setPermission(outputFs, snapshotTmpDir, (short)filesMode, true);
> }
> {code}
> It copy snapshot manifest to initialOutputSnapshotDir, but it set owner on
> snapshotTmpDir. They are different directory when skipTmp is true.
> Another problem is new cluster doesn't have .hbase-snapshot directory. So
> after export snapshot, it should set owner on .hbase-snapshot directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16939) ExportSnapshot: set owner and permission on right directory
[
https://issues.apache.org/jira/browse/HBASE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607013#comment-15607013
]
Guanghao Zhang commented on HBASE-16939:
Thanks for your help. [~mbertozzi]
> ExportSnapshot: set owner and permission on right directory
> ---
>
> Key: HBASE-16939
> URL: https://issues.apache.org/jira/browse/HBASE-16939
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.4, 1.1.8
>
> Attachments: HBASE-16939-v1.patch, HBASE-16939.patch
>
>
> {code}
> FileUtil.copy(inputFs, snapshotDir, outputFs, initialOutputSnapshotDir,
> false, false, conf);
> if (filesUser != null || filesGroup != null) {
> setOwner(outputFs, snapshotTmpDir, filesUser, filesGroup, true);
> }
> if (filesMode > 0) {
> setPermission(outputFs, snapshotTmpDir, (short)filesMode, true);
> }
> {code}
> It copy snapshot manifest to initialOutputSnapshotDir, but it set owner on
> snapshotTmpDir. They are different directory when skipTmp is true.
> Another problem is new cluster doesn't have .hbase-snapshot directory. So
> after export snapshot, it should set owner on .hbase-snapshot directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16940) Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega patch" posted on RB
[ https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-16940: --- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: (was: HBASE-7912) 2.0.0 Status: Resolved (was: Patch Available) Integrated to HBASE-7912 branch. Thanks for the patch, Vlad. > Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega > patch" posted on RB > -- > > Key: HBASE-16940 > URL: https://issues.apache.org/jira/browse/HBASE-16940 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0 > > Attachments: HBASE-16940-v1.patch, HBASE-16940-v2.patch > > > Review 52748 remaining issues. > https://reviews.apache.org/r/52748 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16940) Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega patch" posted on RB
[
https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606936#comment-15606936
]
Hadoop QA commented on HBASE-16940:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s {color}
| {color:red} HBASE-16940 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.3.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12835232/HBASE-16940-v2.patch |
| JIRA Issue | HBASE-16940 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4186/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega
> patch" posted on RB
> --
>
> Key: HBASE-16940
> URL: https://issues.apache.org/jira/browse/HBASE-16940
> Project: HBase
> Issue Type: Sub-task
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Fix For: HBASE-7912
>
> Attachments: HBASE-16940-v1.patch, HBASE-16940-v2.patch
>
>
> Review 52748 remaining issues.
> https://reviews.apache.org/r/52748
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16940) Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega patch" posted on RB
[ https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16940: -- Attachment: HBASE-16940-v2.patch v2. > Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega > patch" posted on RB > -- > > Key: HBASE-16940 > URL: https://issues.apache.org/jira/browse/HBASE-16940 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: HBASE-7912 > > Attachments: HBASE-16940-v1.patch, HBASE-16940-v2.patch > > > Review 52748 remaining issues. > https://reviews.apache.org/r/52748 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16940) Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega patch" posted on RB
[
https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606918#comment-15606918
]
Ted Yu commented on HBASE-16940:
Minor comments after brief check.
For BackupSystemTable :
{code}
-rsTimestampMap.put(server, Long.parseLong(new String(data)));
+//rsTimestampMap.put(server, Long.parseLong(new String(data)));
+rsTimestampMap.put(server, Bytes.toLong(data));
{code}
The commented out line can be dropped.
{code}
+put.addColumn(BackupSystemTable.SESSIONS_FAMILY, Bytes.toBytes("context"),
context.toByteArray());
{code}
Line longer than 100 char
> Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega
> patch" posted on RB
> --
>
> Key: HBASE-16940
> URL: https://issues.apache.org/jira/browse/HBASE-16940
> Project: HBase
> Issue Type: Sub-task
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Fix For: HBASE-7912
>
> Attachments: HBASE-16940-v1.patch
>
>
> Review 52748 remaining issues.
> https://reviews.apache.org/r/52748
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16940) Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega patch" posted on RB
[ https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606904#comment-15606904 ] stack commented on HBASE-16940: --- You need something folks can make some sense of as a subject/commit message. Looking at a commit message that has some random number, review, and miscellaneous means folks have to work had dig up a provenance. > Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega > patch" posted on RB > -- > > Key: HBASE-16940 > URL: https://issues.apache.org/jira/browse/HBASE-16940 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: HBASE-7912 > > Attachments: HBASE-16940-v1.patch > > > Review 52748 remaining issues. > https://reviews.apache.org/r/52748 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16940) Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega patch" posted on RB
[ https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606900#comment-15606900 ] Ted Yu commented on HBASE-16940: Running test suite based on patch v1. > Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega > patch" posted on RB > -- > > Key: HBASE-16940 > URL: https://issues.apache.org/jira/browse/HBASE-16940 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: HBASE-7912 > > Attachments: HBASE-16940-v1.patch > > > Review 52748 remaining issues. > https://reviews.apache.org/r/52748 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16940) Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega patch" posted on RB 52748
[ https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-16940: -- Summary: Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega patch" posted on RB 52748 (was: Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega patch" posted on RB ) > Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega > patch" posted on RB 52748 > > > Key: HBASE-16940 > URL: https://issues.apache.org/jira/browse/HBASE-16940 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: HBASE-7912 > > Attachments: HBASE-16940-v1.patch > > > Review 52748 remaining issues. > https://reviews.apache.org/r/52748 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16940) Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega patch" posted on RB
[ https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-16940: -- Summary: Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega patch" posted on RB (was: Review 52748: Miscellaneous ) > Address review of "Backup/Restore (HBASE-7912, HBASE-14030, HBASE-14123) mega > patch" posted on RB > -- > > Key: HBASE-16940 > URL: https://issues.apache.org/jira/browse/HBASE-16940 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: HBASE-7912 > > Attachments: HBASE-16940-v1.patch > > > Review 52748 remaining issues. > https://reviews.apache.org/r/52748 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16940) Review 52748: Miscellaneous
[
https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606899#comment-15606899
]
Hadoop QA commented on HBASE-16940:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s {color}
| {color:red} HBASE-16940 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.3.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12835230/HBASE-16940-v1.patch |
| JIRA Issue | HBASE-16940 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4185/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Review 52748: Miscellaneous
>
>
> Key: HBASE-16940
> URL: https://issues.apache.org/jira/browse/HBASE-16940
> Project: HBase
> Issue Type: Sub-task
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Fix For: HBASE-7912
>
> Attachments: HBASE-16940-v1.patch
>
>
> Review 52748 remaining issues.
> https://reviews.apache.org/r/52748
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16940) Review 52748: Miscellaneous
[ https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16940: -- Status: Patch Available (was: Open) > Review 52748: Miscellaneous > > > Key: HBASE-16940 > URL: https://issues.apache.org/jira/browse/HBASE-16940 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: HBASE-7912 > > Attachments: HBASE-16940-v1.patch > > > Review 52748 remaining issues. > https://reviews.apache.org/r/52748 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16940) Review 52748: Miscellaneous
[ https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16940: -- Description: Review 52748 remaining issues. https://reviews.apache.org/r/52748 was:Review 52748 remaining issues. > Review 52748: Miscellaneous > > > Key: HBASE-16940 > URL: https://issues.apache.org/jira/browse/HBASE-16940 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: HBASE-7912 > > Attachments: HBASE-16940-v1.patch > > > Review 52748 remaining issues. > https://reviews.apache.org/r/52748 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-16940) Review 52748: Miscellaneous
[ https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606874#comment-15606874 ] Vladimir Rodionov edited comment on HBASE-16940 at 10/26/16 12:08 AM: -- v1. Addresses the rest of comments (majority of them) from RB. [~tedyu], it passes all tests. Lets commit it to HBASE-7912 and I will start working on porting all HBASE-16825 patches to master branch. was (Author: vrodionov): v1. Addresses the rest of comments (majority of them) from RB. > Review 52748: Miscellaneous > > > Key: HBASE-16940 > URL: https://issues.apache.org/jira/browse/HBASE-16940 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: HBASE-7912 > > Attachments: HBASE-16940-v1.patch > > > Review 52748 remaining issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16940) Review 52748: Miscellaneous
[
https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606877#comment-15606877
]
Vladimir Rodionov commented on HBASE-16940:
---
{quote}
This issue needs better subject. As is, it is cryptic.
{quote}
Its hard for the cumulative patch of 30+ RB comments.
> Review 52748: Miscellaneous
>
>
> Key: HBASE-16940
> URL: https://issues.apache.org/jira/browse/HBASE-16940
> Project: HBase
> Issue Type: Sub-task
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Fix For: HBASE-7912
>
> Attachments: HBASE-16940-v1.patch
>
>
> Review 52748 remaining issues.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16940) Review 52748: Miscellaneous
[ https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16940: -- Attachment: HBASE-16940-v1.patch v1. Addresses the rest of comments (majority of them) from RB. > Review 52748: Miscellaneous > > > Key: HBASE-16940 > URL: https://issues.apache.org/jira/browse/HBASE-16940 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: HBASE-7912 > > Attachments: HBASE-16940-v1.patch > > > Review 52748 remaining issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16939) ExportSnapshot: set owner and permission on right directory
[
https://issues.apache.org/jira/browse/HBASE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606847#comment-15606847
]
Hudson commented on HBASE-16939:
FAILURE: Integrated in Jenkins build HBase-1.1-JDK7 #1805 (See
[https://builds.apache.org/job/HBase-1.1-JDK7/1805/])
HBASE-16939 ExportSnapshot: set owner and permission on right directory
(matteo.bertozzi: rev 288ea316be7039c9361ffba7061d6a68154e633c)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/ExportSnapshot.java
> ExportSnapshot: set owner and permission on right directory
> ---
>
> Key: HBASE-16939
> URL: https://issues.apache.org/jira/browse/HBASE-16939
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.4, 1.1.8
>
> Attachments: HBASE-16939-v1.patch, HBASE-16939.patch
>
>
> {code}
> FileUtil.copy(inputFs, snapshotDir, outputFs, initialOutputSnapshotDir,
> false, false, conf);
> if (filesUser != null || filesGroup != null) {
> setOwner(outputFs, snapshotTmpDir, filesUser, filesGroup, true);
> }
> if (filesMode > 0) {
> setPermission(outputFs, snapshotTmpDir, (short)filesMode, true);
> }
> {code}
> It copy snapshot manifest to initialOutputSnapshotDir, but it set owner on
> snapshotTmpDir. They are different directory when skipTmp is true.
> Another problem is new cluster doesn't have .hbase-snapshot directory. So
> after export snapshot, it should set owner on .hbase-snapshot directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16939) ExportSnapshot: set owner and permission on right directory
[
https://issues.apache.org/jira/browse/HBASE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606841#comment-15606841
]
Hudson commented on HBASE-16939:
SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #1854 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/1854/])
HBASE-16939 ExportSnapshot: set owner and permission on right directory
(matteo.bertozzi: rev c4be87d0508cda019c15f929396d053887bf0e5e)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/ExportSnapshot.java
> ExportSnapshot: set owner and permission on right directory
> ---
>
> Key: HBASE-16939
> URL: https://issues.apache.org/jira/browse/HBASE-16939
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.4, 1.1.8
>
> Attachments: HBASE-16939-v1.patch, HBASE-16939.patch
>
>
> {code}
> FileUtil.copy(inputFs, snapshotDir, outputFs, initialOutputSnapshotDir,
> false, false, conf);
> if (filesUser != null || filesGroup != null) {
> setOwner(outputFs, snapshotTmpDir, filesUser, filesGroup, true);
> }
> if (filesMode > 0) {
> setPermission(outputFs, snapshotTmpDir, (short)filesMode, true);
> }
> {code}
> It copy snapshot manifest to initialOutputSnapshotDir, but it set owner on
> snapshotTmpDir. They are different directory when skipTmp is true.
> Another problem is new cluster doesn't have .hbase-snapshot directory. So
> after export snapshot, it should set owner on .hbase-snapshot directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (HBASE-16453) Test failure TestHRegion.testWritesWhileScanning
[
https://issues.apache.org/jira/browse/HBASE-16453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-16453.
---
Resolution: Incomplete
Resolving incomplete. I don't think we have this any more.
> Test failure TestHRegion.testWritesWhileScanning
>
>
> Key: HBASE-16453
> URL: https://issues.apache.org/jira/browse/HBASE-16453
> Project: HBase
> Issue Type: Bug
>Reporter: Anoop Sam John
>
> Latest builds show this fail
> {code}
> org.junit.runners.model.TestTimedOutException: test timed out after 10 minutes
> at java.lang.Object.wait(Native Method)
> at
> org.apache.hadoop.hbase.regionserver.MultiVersionConcurrencyControl.waitForRead(MultiVersionConcurrencyControl.java:218)
> at
> org.apache.hadoop.hbase.regionserver.MultiVersionConcurrencyControl.completeAndWait(MultiVersionConcurrencyControl.java:149)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getNextSequenceId(HRegion.java:2604)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalPrepareFlushCache(HRegion.java:2321)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2217)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2188)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2178)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doClose(HRegion.java:1484)
> at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1412)
> at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1362)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.closeRegionAndWAL(HBaseTestingUtility.java:369)
> at
> org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileScanning(TestHRegion.java:3962)
> {code}
> An MVCC stuck.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606785#comment-15606785 ] stack commented on HBASE-16890: --- The disruptor consumer thread would feed the eventloop? Could. Another thought was just collect the appends and not assign the trans id until we are going to sync since that is when we add the edit to the WAL and given that the write path is different in master -- we don't update memstore until after sync has come home -- then this could work. One node is bringing out the fact that asyncfswal currently does not run as free as dfsclient#dfsos and the latter is friction-full with its packet-stutter. You've made it so it is easy to work on this now. No rush -- asyncwal is better than dfsclient in a couple of regards -- but yeah, lets make it so asyncwal blows away dfsclient any way you look at it. > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16939) ExportSnapshot: set owner and permission on right directory
[
https://issues.apache.org/jira/browse/HBASE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606766#comment-15606766
]
Hudson commented on HBASE-16939:
FAILURE: Integrated in Jenkins build HBase-1.1-JDK8 #1889 (See
[https://builds.apache.org/job/HBase-1.1-JDK8/1889/])
HBASE-16939 ExportSnapshot: set owner and permission on right directory
(matteo.bertozzi: rev 288ea316be7039c9361ffba7061d6a68154e633c)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/ExportSnapshot.java
> ExportSnapshot: set owner and permission on right directory
> ---
>
> Key: HBASE-16939
> URL: https://issues.apache.org/jira/browse/HBASE-16939
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.4, 1.1.8
>
> Attachments: HBASE-16939-v1.patch, HBASE-16939.patch
>
>
> {code}
> FileUtil.copy(inputFs, snapshotDir, outputFs, initialOutputSnapshotDir,
> false, false, conf);
> if (filesUser != null || filesGroup != null) {
> setOwner(outputFs, snapshotTmpDir, filesUser, filesGroup, true);
> }
> if (filesMode > 0) {
> setPermission(outputFs, snapshotTmpDir, (short)filesMode, true);
> }
> {code}
> It copy snapshot manifest to initialOutputSnapshotDir, but it set owner on
> snapshotTmpDir. They are different directory when skipTmp is true.
> Another problem is new cluster doesn't have .hbase-snapshot directory. So
> after export snapshot, it should set owner on .hbase-snapshot directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606750#comment-15606750 ] Duo Zhang commented on HBASE-16890: --- [~stack] I think a simple way to avoid the contention is to use a disruptor in front of the old logic. This will need one more thread. But do you guys really think we should do optimizations based on the one node result? In a production we will write at least three node? > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606735#comment-15606735 ] Duo Zhang commented on HBASE-16890: --- [~ram_krish] But AsyncFSWAL will not do flushing unless you call the flush method. So the problem is still what I said above, AsyncFSWAL may flush more. Otherwise there is no difference. Thanks. > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12894) Upgrade Jetty to 9.2.6
[ https://issues.apache.org/jira/browse/HBASE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606719#comment-15606719 ] stack commented on HBASE-12894: --- The complaint about ServerConnector in Builder from FindBugs seems legit. Why are we acting like it is going to be set in the Builder when no one does it. I took a look at it and doesn't make sense to me. Maybe you have a clue Mr. [~yguang11] Thanks. What about the REST FindBugs complaints too? Thank you. > Upgrade Jetty to 9.2.6 > -- > > Key: HBASE-12894 > URL: https://issues.apache.org/jira/browse/HBASE-12894 > Project: HBase > Issue Type: Improvement > Components: REST, UI >Affects Versions: 0.98.0 >Reporter: Rick Hallihan >Assignee: Guang Yang >Priority: Critical > Labels: MicrosoftSupport > Fix For: 2.0.0 > > Attachments: HBASE-12894_Jetty9_v0.patch, > HBASE-12894_Jetty9_v1.patch, HBASE-12894_Jetty9_v1.patch, > HBASE-12894_Jetty9_v2.patch, HBASE-12894_Jetty9_v3.patch > > > The Jetty component that is used for the HBase Stargate REST endpoint is > version 6.1.26 and is fairly outdated. We recently had a customer inquire > about enabling cross-origin resource sharing (CORS) for the REST endpoint and > found that this older version does not include the necessary filter or > configuration options, highlighted at: > http://wiki.eclipse.org/Jetty/Feature/Cross_Origin_Filter > The Jetty project has had significant updates through versions 7, 8 and 9, > including a transition to be an Eclipse subproject, so updating to the latest > version may be non-trivial. The last update to the Jetty component in > https://issues.apache.org/jira/browse/HBASE-3377 was a minor version update > and did not require significant work. This update will include a package > namespace update so there will likely be a larger number of required changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16939) ExportSnapshot: set owner and permission on right directory
[
https://issues.apache.org/jira/browse/HBASE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-16939:
Fix Version/s: (was: 1.2.5)
1.2.4
> ExportSnapshot: set owner and permission on right directory
> ---
>
> Key: HBASE-16939
> URL: https://issues.apache.org/jira/browse/HBASE-16939
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.4, 1.1.8
>
> Attachments: HBASE-16939-v1.patch, HBASE-16939.patch
>
>
> {code}
> FileUtil.copy(inputFs, snapshotDir, outputFs, initialOutputSnapshotDir,
> false, false, conf);
> if (filesUser != null || filesGroup != null) {
> setOwner(outputFs, snapshotTmpDir, filesUser, filesGroup, true);
> }
> if (filesMode > 0) {
> setPermission(outputFs, snapshotTmpDir, (short)filesMode, true);
> }
> {code}
> It copy snapshot manifest to initialOutputSnapshotDir, but it set owner on
> snapshotTmpDir. They are different directory when skipTmp is true.
> Another problem is new cluster doesn't have .hbase-snapshot directory. So
> after export snapshot, it should set owner on .hbase-snapshot directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (HBASE-16944) Fix findbugs warning in hbase-server HRegion UL_UNRELEASED_LOCK
[
https://issues.apache.org/jira/browse/HBASE-16944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-16944.
---
Resolution: Fixed
Pushed this:
{code}
diff --git
a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
index 71cc247..7bfd652 100644
---
a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
+++
b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
@@ -3025,6 +3025,8 @@ public class HRegion implements HeapSize,
PropagatingConfigurationObserver, Regi
* In here we also handle replay of edits on region recover.
* @return Change in size brought about by applying batchOp
*/
+ @edu.umd.cs.findbugs.annotations.SuppressWarnings(value="UL_UNRELEASED_LOCK",
+ justification="Findbugs seems to be confused on this.")
@SuppressWarnings("unchecked")
// TODO: This needs a rewrite. Doesn't have to be this long. St.Ack 20160120
private long doMiniBatchMutate(BatchOperation batchOp) throws IOException
{
{code}
> Fix findbugs warning in hbase-server HRegion UL_UNRELEASED_LOCK
> ---
>
> Key: HBASE-16944
> URL: https://issues.apache.org/jira/browse/HBASE-16944
> Project: HBase
> Issue Type: Bug
> Components: findbugs
>Reporter: stack
>
> Fix the annoying long-lived UL_UNRELEASED_LOCK warning out of line 3251 in
> HRegion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16944) Fix findbugs warning in hbase-server HRegion UL_UNRELEASED_LOCK
[ https://issues.apache.org/jira/browse/HBASE-16944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606565#comment-15606565 ] stack commented on HBASE-16944: --- CodeWarning UL org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutate(HRegion$BatchOperation) does not release lock on all paths Bug type UL_UNRELEASED_LOCK (click for details) In class org.apache.hadoop.hbase.regionserver.HRegion In method org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutate(HRegion$BatchOperation) At HRegion.java:[line 3251] > Fix findbugs warning in hbase-server HRegion UL_UNRELEASED_LOCK > --- > > Key: HBASE-16944 > URL: https://issues.apache.org/jira/browse/HBASE-16944 > Project: HBase > Issue Type: Bug > Components: findbugs >Reporter: stack > > Fix the annoying long-lived UL_UNRELEASED_LOCK warning out of line 3251 in > HRegion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-16944) Fix findbugs warning in hbase-server HRegion UL_UNRELEASED_LOCK
stack created HBASE-16944: - Summary: Fix findbugs warning in hbase-server HRegion UL_UNRELEASED_LOCK Key: HBASE-16944 URL: https://issues.apache.org/jira/browse/HBASE-16944 Project: HBase Issue Type: Bug Components: findbugs Reporter: stack Fix the annoying long-lived UL_UNRELEASED_LOCK warning out of line 3251 in HRegion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16939) ExportSnapshot: set owner and permission on right directory
[
https://issues.apache.org/jira/browse/HBASE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-16939:
Fix Version/s: (was: 1.2.4)
1.2.5
> ExportSnapshot: set owner and permission on right directory
> ---
>
> Key: HBASE-16939
> URL: https://issues.apache.org/jira/browse/HBASE-16939
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.5, 1.1.8
>
> Attachments: HBASE-16939-v1.patch, HBASE-16939.patch
>
>
> {code}
> FileUtil.copy(inputFs, snapshotDir, outputFs, initialOutputSnapshotDir,
> false, false, conf);
> if (filesUser != null || filesGroup != null) {
> setOwner(outputFs, snapshotTmpDir, filesUser, filesGroup, true);
> }
> if (filesMode > 0) {
> setPermission(outputFs, snapshotTmpDir, (short)filesMode, true);
> }
> {code}
> It copy snapshot manifest to initialOutputSnapshotDir, but it set owner on
> snapshotTmpDir. They are different directory when skipTmp is true.
> Another problem is new cluster doesn't have .hbase-snapshot directory. So
> after export snapshot, it should set owner on .hbase-snapshot directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16939) ExportSnapshot: set owner and permission on right directory
[
https://issues.apache.org/jira/browse/HBASE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-16939:
Resolution: Fixed
Fix Version/s: 1.1.8
1.2.4
1.3.1
1.4.0
2.0.0
Status: Resolved (was: Patch Available)
> ExportSnapshot: set owner and permission on right directory
> ---
>
> Key: HBASE-16939
> URL: https://issues.apache.org/jira/browse/HBASE-16939
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.4, 1.1.8
>
> Attachments: HBASE-16939-v1.patch, HBASE-16939.patch
>
>
> {code}
> FileUtil.copy(inputFs, snapshotDir, outputFs, initialOutputSnapshotDir,
> false, false, conf);
> if (filesUser != null || filesGroup != null) {
> setOwner(outputFs, snapshotTmpDir, filesUser, filesGroup, true);
> }
> if (filesMode > 0) {
> setPermission(outputFs, snapshotTmpDir, (short)filesMode, true);
> }
> {code}
> It copy snapshot manifest to initialOutputSnapshotDir, but it set owner on
> snapshotTmpDir. They are different directory when skipTmp is true.
> Another problem is new cluster doesn't have .hbase-snapshot directory. So
> after export snapshot, it should set owner on .hbase-snapshot directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16939) ExportSnapshot: set owner and permission on right directory
[
https://issues.apache.org/jira/browse/HBASE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606500#comment-15606500
]
Matteo Bertozzi commented on HBASE-16939:
-
committed on 1.1, 1.2, branch-1, master. holding on 1.3 since we are trying to
get a release, i'll commit it later for 1.3.1
(for 0.98, open a backport jira for both HBASE-14445 and this one if you need
this stuff in 0.98)
> ExportSnapshot: set owner and permission on right directory
> ---
>
> Key: HBASE-16939
> URL: https://issues.apache.org/jira/browse/HBASE-16939
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Attachments: HBASE-16939-v1.patch, HBASE-16939.patch
>
>
> {code}
> FileUtil.copy(inputFs, snapshotDir, outputFs, initialOutputSnapshotDir,
> false, false, conf);
> if (filesUser != null || filesGroup != null) {
> setOwner(outputFs, snapshotTmpDir, filesUser, filesGroup, true);
> }
> if (filesMode > 0) {
> setPermission(outputFs, snapshotTmpDir, (short)filesMode, true);
> }
> {code}
> It copy snapshot manifest to initialOutputSnapshotDir, but it set owner on
> snapshotTmpDir. They are different directory when skipTmp is true.
> Another problem is new cluster doesn't have .hbase-snapshot directory. So
> after export snapshot, it should set owner on .hbase-snapshot directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606424#comment-15606424 ] stack commented on HBASE-16890: --- I did a primitive compare with 100 threads, 10 columns on WALPE. The classic FSHLog in JFR shows a few instances of FSOutputSummer#write and DFSOS#flushOrSync in samples (7 and 3 respectively). The asyncwal by contrast has two orders of magnitude more points of contention showing up in samples at append and sync (900 and 200). The sync on waitingConsumePayloads is a throughput killer. > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606423#comment-15606423 ] stack commented on HBASE-16890: --- I did a primitive compare with 100 threads, 10 columns on WALPE. The classic FSHLog in JFR shows a few instances of FSOutputSummer#write and DFSOS#flushOrSync in samples (7 and 3 respectively). The asyncwal by contrast has two orders of magnitude more points of contention showing up in samples at append and sync (900 and 200). The sync on waitingConsumePayloads is a throughput killer. > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-1600) Multiple HBase clients to multiple indpendent HBase clusters from the same jvm should be allowed
[ https://issues.apache.org/jira/browse/HBASE-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606275#comment-15606275 ] Hudson commented on HBASE-1600: --- SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #1853 (See [https://builds.apache.org/job/HBase-Trunk_matrix/1853/]) HBASE-1600 Table#checkAndPut() docs are too vague (Csaba Skrabak) (stack: rev 36aa41685685f6b7d10fea63787cb8adacecc2e7) * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Table.java > Multiple HBase clients to multiple indpendent HBase clusters from the same > jvm should be allowed > > > Key: HBASE-1600 > URL: https://issues.apache.org/jira/browse/HBASE-1600 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.20.0 >Reporter: Chris K Wensel >Assignee: Nitay Joffe >Priority: Blocker > > ZK quorum servers list is static in ZooKeeperWrapper and is coupled to > zoo.cfg. > This prevents multiple clients from connecting to multiple distinct HBase > clusters and requires zoo.cfg to exist on a cluster that needs to connect to > a remote HBase cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12894) Upgrade Jetty to 9.2.6
[ https://issues.apache.org/jira/browse/HBASE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606066#comment-15606066 ] Guang Yang commented on HBASE-12894: Hi [~stack], Please let me know if there is anything you want me to do for this patch so as to commit it, thanks! > Upgrade Jetty to 9.2.6 > -- > > Key: HBASE-12894 > URL: https://issues.apache.org/jira/browse/HBASE-12894 > Project: HBase > Issue Type: Improvement > Components: REST, UI >Affects Versions: 0.98.0 >Reporter: Rick Hallihan >Assignee: Guang Yang >Priority: Critical > Labels: MicrosoftSupport > Fix For: 2.0.0 > > Attachments: HBASE-12894_Jetty9_v0.patch, > HBASE-12894_Jetty9_v1.patch, HBASE-12894_Jetty9_v1.patch, > HBASE-12894_Jetty9_v2.patch, HBASE-12894_Jetty9_v3.patch > > > The Jetty component that is used for the HBase Stargate REST endpoint is > version 6.1.26 and is fairly outdated. We recently had a customer inquire > about enabling cross-origin resource sharing (CORS) for the REST endpoint and > found that this older version does not include the necessary filter or > configuration options, highlighted at: > http://wiki.eclipse.org/Jetty/Feature/Cross_Origin_Filter > The Jetty project has had significant updates through versions 7, 8 and 9, > including a transition to be an Eclipse subproject, so updating to the latest > version may be non-trivial. The last update to the Jetty component in > https://issues.apache.org/jira/browse/HBASE-3377 was a minor version update > and did not require significant work. This update will include a package > namespace update so there will likely be a larger number of required changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0
[ https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606070#comment-15606070 ] Ted Yu commented on HBASE-16179: Here is a related thread for a poll on dropping support for Scala 2.10 : http://search-hadoop.com/m/Spark/q3RTtwK7l612MKAk?subj=Re+Straw+poll+dropping+support+for+things+like+Scala+2+10 > Fix compilation errors when building hbase-spark against Spark 2.0 > -- > > Key: HBASE-16179 > URL: https://issues.apache.org/jira/browse/HBASE-16179 > Project: HBase > Issue Type: Bug > Components: spark >Reporter: Ted Yu >Assignee: Ted Yu >Priority: Critical > Fix For: 2.0.0 > > Attachments: 16179.v0.txt, 16179.v1.txt, 16179.v1.txt, 16179.v10.txt, > 16179.v11.txt, 16179.v4.txt, 16179.v5.txt, 16179.v7.txt, 16179.v8.txt, > 16179.v9.txt > > > I tried building hbase-spark module against Spark-2.0 snapshot and got the > following compilation errors: > http://pastebin.com/bg3w247a > Some Spark classes such as DataTypeParser and Logging are no longer > accessible to downstream projects. > hbase-spark module should not depend on such classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16931) Setting cell's seqId to zero in compaction flow might cause RS down.
[
https://issues.apache.org/jira/browse/HBASE-16931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606042#comment-15606042
]
Hudson commented on HBASE-16931:
SUCCESS: Integrated in Jenkins build HBase-1.2-JDK7 #55 (See
[https://builds.apache.org/job/HBase-1.2-JDK7/55/])
HBASE-16931 Setting cell's seqId to zero in compaction flow might cause (liyu:
rev 7f10379b1e6756002993c2638c866a6537a088c4)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompaction.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/Compactor.java
> Setting cell's seqId to zero in compaction flow might cause RS down.
>
>
> Key: HBASE-16931
> URL: https://issues.apache.org/jira/browse/HBASE-16931
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: binlijin
>Assignee: binlijin
>Priority: Critical
> Fix For: 2.0.0, 1.4.0, 1.2.4, 1.1.8
>
> Attachments: HBASE-16931-master.patch, HBASE-16931.branch-1.patch,
> HBASE-16931.branch-1.v2.patch, HBASE-16931_master_v2.patch,
> HBASE-16931_master_v3.patch, HBASE-16931_master_v4.patch,
> HBASE-16931_master_v5.patch
>
>
> Compactor#performCompaction
> do {
> hasMore = scanner.next(cells, scannerContext);
> // output to writer:
> for (Cell c : cells) {
> if (cleanSeqId && c.getSequenceId() <= smallestReadPoint) {
> CellUtil.setSequenceId(c, 0);
> }
> writer.append(c);
> }
> cells.clear();
> } while (hasMore);
> scanner.next will choose at most "hbase.hstore.compaction.kv.max" kvs, the
> last cell still reference by StoreScanner.prevCell, so if cleanSeqId is
> called when the scanner.next call StoreScanner.checkScanOrder may throw
> exception and cause regionserver down.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605994#comment-15605994 ] ramkrishna.s.vasudevan commented on HBASE-16890: Some updates here. Read the code and discussed internally on how things work. Need to do some verification in cluster tomorrow. Will report back. MAy be what i think is that In FSHLog case once the data was equal to (512 * 9) bytes we were flushing the buffer and that flush was resulting in a chunk packet ( which is part of the bigger chunk 64K). So only when the sync is called we may end up in non-aligned chunks. All this happens on the dfs client side. On the DN side when it sees the unaligned block it tries to overwrite the CRC of the current block with the previous block CRC. Now in the FSHLog case we may get only the one chunk packet as unaligned per sync call. But in case of AsyncHLog every packet we generate will mostly be unaligned and so the DN needs to do the extra work of overwriting the CRC every time. This is what I see from code but let me profile the DN also to verify. I may be wrong. Will come back here. From HBase side profiling not much is revealed as per my tests. > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-16943) FN Interfaces for writing tools for monitoring/operations
Thiruvel Thirumoolan created HBASE-16943: Summary: FN Interfaces for writing tools for monitoring/operations Key: HBASE-16943 URL: https://issues.apache.org/jira/browse/HBASE-16943 Project: HBase Issue Type: Sub-task Reporter: Thiruvel Thirumoolan Assignee: Thiruvel Thirumoolan Fix For: 2.0.0 HBASE-15532 introduces new interfaces and tools. This sub-task is only for the new interfaces and their implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-16942) FavoredNodes - Balancer improvements
Thiruvel Thirumoolan created HBASE-16942: Summary: FavoredNodes - Balancer improvements Key: HBASE-16942 URL: https://issues.apache.org/jira/browse/HBASE-16942 Project: HBase Issue Type: Sub-task Reporter: Thiruvel Thirumoolan Assignee: Thiruvel Thirumoolan Fix For: 2.0.0 This deals with the balancer based enhancements to favored nodes patch as discussed in HBASE-15532. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-16941) FavoredNodes - Split/Merge code paths
Thiruvel Thirumoolan created HBASE-16941: Summary: FavoredNodes - Split/Merge code paths Key: HBASE-16941 URL: https://issues.apache.org/jira/browse/HBASE-16941 Project: HBase Issue Type: Sub-task Reporter: Thiruvel Thirumoolan Assignee: Thiruvel Thirumoolan Fix For: 2.0.0 This jira is to deal with the split/merge logic discussed as part of HBASE-15532. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16940) Review 52748: Miscellaneous
[ https://issues.apache.org/jira/browse/HBASE-16940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605935#comment-15605935 ] stack commented on HBASE-16940: --- This issue needs better subject. As is, it is cryptic. > Review 52748: Miscellaneous > > > Key: HBASE-16940 > URL: https://issues.apache.org/jira/browse/HBASE-16940 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: HBASE-7912 > > > Review 52748 remaining issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16931) Setting cell's seqId to zero in compaction flow might cause RS down.
[
https://issues.apache.org/jira/browse/HBASE-16931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605931#comment-15605931
]
Hudson commented on HBASE-16931:
SUCCESS: Integrated in Jenkins build HBase-1.2-JDK8 #50 (See
[https://builds.apache.org/job/HBase-1.2-JDK8/50/])
HBASE-16931 Setting cell's seqId to zero in compaction flow might cause (liyu:
rev 7f10379b1e6756002993c2638c866a6537a088c4)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompaction.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/Compactor.java
> Setting cell's seqId to zero in compaction flow might cause RS down.
>
>
> Key: HBASE-16931
> URL: https://issues.apache.org/jira/browse/HBASE-16931
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: binlijin
>Assignee: binlijin
>Priority: Critical
> Fix For: 2.0.0, 1.4.0, 1.2.4, 1.1.8
>
> Attachments: HBASE-16931-master.patch, HBASE-16931.branch-1.patch,
> HBASE-16931.branch-1.v2.patch, HBASE-16931_master_v2.patch,
> HBASE-16931_master_v3.patch, HBASE-16931_master_v4.patch,
> HBASE-16931_master_v5.patch
>
>
> Compactor#performCompaction
> do {
> hasMore = scanner.next(cells, scannerContext);
> // output to writer:
> for (Cell c : cells) {
> if (cleanSeqId && c.getSequenceId() <= smallestReadPoint) {
> CellUtil.setSequenceId(c, 0);
> }
> writer.append(c);
> }
> cells.clear();
> } while (hasMore);
> scanner.next will choose at most "hbase.hstore.compaction.kv.max" kvs, the
> last cell still reference by StoreScanner.prevCell, so if cleanSeqId is
> called when the scanner.next call StoreScanner.checkScanOrder may throw
> exception and cause regionserver down.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16934) Revert ITBLL misconfiguration check introduced in HBASE-16562
[ https://issues.apache.org/jira/browse/HBASE-16934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605910#comment-15605910 ] Hudson commented on HBASE-16934: FAILURE: Integrated in Jenkins build HBase-0.98-on-Hadoop-1.1 #1284 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/1284/]) HBASE-16934 Revert ITBLL misconfiguration check that results in NPE. (busbey: rev f475e54bef96a3817e4807c8bd21f841d1492b2a) * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/test/IntegrationTestBigLinkedList.java > Revert ITBLL misconfiguration check introduced in HBASE-16562 > - > > Key: HBASE-16934 > URL: https://issues.apache.org/jira/browse/HBASE-16934 > Project: HBase > Issue Type: Bug > Components: integration tests >Affects Versions: 1.1.7, 0.98.23 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 0.98.24, 1.1.8 > > > The misconfiguration check in HBASE-16562 does insufficient input validation > / handling, resulting in a NPE during normal operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14551) Procedure v2 - Reimplement split
[
https://issues.apache.org/jira/browse/HBASE-14551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605896#comment-15605896
]
Hadoop QA commented on HBASE-14551:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 9 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 7s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
0s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 27s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 13m
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
39s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 49s
{color} | {color:red} hbase-protocol-shaded in master has 24 extant Findbugs
warnings. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 39s
{color} | {color:red} hbase-server in master has 1 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 59s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 8s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
42s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 28s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 28s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 28s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 14m
33s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
39s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 19 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
28m 3s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
32s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 17s
{color} | {color:red} hbase-client generated 1 new + 13 unchanged - 0 fixed =
14 total (was 13) {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 28s
{color} | {color:red} hbase-server generated 3 new + 1 unchanged - 0 fixed = 4
total (was 1) {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 28s
{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 54s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 85m 31s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 23s
{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m 46s
{color} | {color:red} The patch generated 1 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 167m 17s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.security.access.TestAccessController |
| | hadoop.hbase.regionserver.TestSplitTransactionOnCluster |
| | hadoop.hbase.namespace.TestNamespaceAuditor |
| | hadoop.hbase.mapreduce.TestLoadIncrementalHFilesSplitRecovery |
| | hadoop.hbase.mapreduce.TestSecureLoadIncrementalHFilesSpli
[jira] [Commented] (HBASE-14417) Incremental backup and bulk loading
[ https://issues.apache.org/jira/browse/HBASE-14417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605864#comment-15605864 ] Ted Yu commented on HBASE-14417: In IncrementalTableBackupClient, before marking the backup complete, I am adding code to copy the bulk loaded hfiles to destination filesystem and persist the list of copied files to hbase:backup table. > Incremental backup and bulk loading > --- > > Key: HBASE-14417 > URL: https://issues.apache.org/jira/browse/HBASE-14417 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: Vladimir Rodionov >Assignee: Ted Yu >Priority: Critical > Labels: backup > Fix For: 2.0.0 > > Attachments: 14417.v1.txt, 14417.v11.txt, 14417.v13.txt, > 14417.v2.txt, 14417.v6.txt > > > Currently, incremental backup is based on WAL files. Bulk data loading > bypasses WALs for obvious reasons, breaking incremental backups. The only way > to continue backups after bulk loading is to create new full backup of a > table. This may not be feasible for customers who do bulk loading regularly > (say, every day). > Google doc for design: > https://docs.google.com/document/d/1ACCLsecHDvzVSasORgqqRNrloGx4mNYIbvAU7lq5lJE -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16841) Data loss in MOB files after cloning a snapshot and deleting that snapshot
[
https://issues.apache.org/jira/browse/HBASE-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605758#comment-15605758
]
stack commented on HBASE-16841:
---
Patch LGTM but good to get [~mbertozzi]'s opinion [~jingcheng...@intel.com] He
is out the next few days but will be back sir.
> Data loss in MOB files after cloning a snapshot and deleting that snapshot
> --
>
> Key: HBASE-16841
> URL: https://issues.apache.org/jira/browse/HBASE-16841
> Project: HBase
> Issue Type: Bug
> Components: mob, snapshots
>Reporter: Jingcheng Du
>Assignee: Jingcheng Du
> Attachments: HBASE-16841-V2.patch, HBASE-16841-V3.patch,
> HBASE-16841.patch
>
>
> Running the following steps will probably lose MOB data when working with
> snapshots.
> 1. Create a mob-enabled table by running create 't1', {NAME => 'f1', IS_MOB
> => true, MOB_THRESHOLD => 0}.
> 2. Put millions of data.
> 3. Run {{snapshot 't1','t1_snapshot'}} to take a snapshot for this table t1.
> 4. Run {{clone_snapshot 't1_snapshot','t1_cloned'}} to clone this snapshot.
> 5. Run {{delete_snapshot 't1_snapshot'}} to delete this snapshot.
> 6. Run {{disable 't1'}} and {{delete 't1'}} to delete the table.
> 7. Now go to the archive directory of t1, the number of .link directories is
> different from the number of hfiles which means some data will be lost after
> the hfile cleaner runs.
> This is because, when taking a snapshot on a enabled mob table, each region
> flushes itself and takes a snapshot, and the mob snapshot is taken only if
> the current region is first region of the table. At that time, the flushing
> of some regions might not be finished, and some mob files are not flushed to
> disk yet. Eventually some mob files are not recorded in the snapshot manifest.
> To solve this, we need to take the mob snapshot at last after the snapshots
> on all the online and offline regions are finished in
> {{EnabledTableSnapshotHandler}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16000) Table#checkAndPut() docs are too vague
[
https://issues.apache.org/jira/browse/HBASE-16000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-16000:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 2.0.0
Status: Resolved (was: Patch Available)
Pushed to master. Thanks for the fixup [~cskrabak]
> Table#checkAndPut() docs are too vague
> --
>
> Key: HBASE-16000
> URL: https://issues.apache.org/jira/browse/HBASE-16000
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Nick Dimiduk
>Assignee: Csaba Skrabak
>Priority: Minor
> Labels: beginner, beginners
> Fix For: 2.0.0
>
> Attachments: hbase-16000.patch
>
>
> The docs for our CAS operations that accept a {{CompareOp}} are too vague.
> They're copied from the part that implies {{CompareOp.EQUAL}}, which means
> they don't tell you how your op, the provided {{value}}, and any present
> value are compared.
> Only by digging into HRegion.java can I see that the operation is, for
> example with CompareOp.GREATER, we get {{value.compareTo(existingKeyValue) >
> 0}}. Javadocs should be explicit about the order of operands.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16932) Implement small scan
[ https://issues.apache.org/jira/browse/HBASE-16932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605732#comment-15605732 ] stack commented on HBASE-16932: --- I think this a good first cut. I think calling it as it is -- smallScan -- is the way to go. Get another opinion given this is going to be public API ([~carp84]?) > Implement small scan > > > Key: HBASE-16932 > URL: https://issues.apache.org/jira/browse/HBASE-16932 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-16932.patch > > > As said in HBASE-16838, we should have a scan method that returns a > CompletaFuture for the whole result. It is suitable for a small scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605707#comment-15605707 ] stack commented on HBASE-16890: --- bq. There is no contention for the synchronization in DFSClient#DFSOS for our FSHLog. We always call it in the consumer thread of Disruptor... In FSHLog there is the consumer thread of Disruptor plus five syncer threads all banging on DFSClient#DFSOS. > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14417) Incremental backup and bulk loading
[ https://issues.apache.org/jira/browse/HBASE-14417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605689#comment-15605689 ] Ted Yu commented on HBASE-14417: When running TestFullRestore, I found an interesting issue: bulk load can happen to the table which is fully backed up - when overwrite option is specified. I can think of two ways to omit these bulk loaded files: 1. under backup zookeeper subtree, create znode with tables which are being restored to with overwrite option. This allows the postAppend() hook to skip these tables for the duration of the restore 2. at the end of bulk load, issue deletes against the znodes which are added during the bulk load I am leaning toward first option. > Incremental backup and bulk loading > --- > > Key: HBASE-14417 > URL: https://issues.apache.org/jira/browse/HBASE-14417 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: Vladimir Rodionov >Assignee: Ted Yu >Priority: Critical > Labels: backup > Fix For: 2.0.0 > > Attachments: 14417.v1.txt, 14417.v11.txt, 14417.v13.txt, > 14417.v2.txt, 14417.v6.txt > > > Currently, incremental backup is based on WAL files. Bulk data loading > bypasses WALs for obvious reasons, breaking incremental backups. The only way > to continue backups after bulk loading is to create new full backup of a > table. This may not be feasible for customers who do bulk loading regularly > (say, every day). > Google doc for design: > https://docs.google.com/document/d/1ACCLsecHDvzVSasORgqqRNrloGx4mNYIbvAU7lq5lJE -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16931) Setting cell's seqId to zero in compaction flow might cause RS down.
[
https://issues.apache.org/jira/browse/HBASE-16931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605663#comment-15605663
]
Hudson commented on HBASE-16931:
FAILURE: Integrated in Jenkins build HBase-1.1-JDK7 #1804 (See
[https://builds.apache.org/job/HBase-1.1-JDK7/1804/])
HBASE-16931 Setting cell's seqId to zero in compaction flow might cause (liyu:
rev f4cbf77f28a2668743b1c73b5aeb113c3456fb13)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompaction.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/Compactor.java
> Setting cell's seqId to zero in compaction flow might cause RS down.
>
>
> Key: HBASE-16931
> URL: https://issues.apache.org/jira/browse/HBASE-16931
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: binlijin
>Assignee: binlijin
>Priority: Critical
> Fix For: 2.0.0, 1.4.0, 1.2.4, 1.1.8
>
> Attachments: HBASE-16931-master.patch, HBASE-16931.branch-1.patch,
> HBASE-16931.branch-1.v2.patch, HBASE-16931_master_v2.patch,
> HBASE-16931_master_v3.patch, HBASE-16931_master_v4.patch,
> HBASE-16931_master_v5.patch
>
>
> Compactor#performCompaction
> do {
> hasMore = scanner.next(cells, scannerContext);
> // output to writer:
> for (Cell c : cells) {
> if (cleanSeqId && c.getSequenceId() <= smallestReadPoint) {
> CellUtil.setSequenceId(c, 0);
> }
> writer.append(c);
> }
> cells.clear();
> } while (hasMore);
> scanner.next will choose at most "hbase.hstore.compaction.kv.max" kvs, the
> last cell still reference by StoreScanner.prevCell, so if cleanSeqId is
> called when the scanner.next call StoreScanner.checkScanOrder may throw
> exception and cause regionserver down.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16112) TestFlushSnapshotFromClient and TestMobFlushSnapshotFromClient are flaky
[
https://issues.apache.org/jira/browse/HBASE-16112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605647#comment-15605647
]
Ted Yu commented on HBASE-16112:
HBASE-16841 would make these tests more stable, right ?
> TestFlushSnapshotFromClient and TestMobFlushSnapshotFromClient are flaky
>
>
> Key: HBASE-16112
> URL: https://issues.apache.org/jira/browse/HBASE-16112
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Jingcheng Du
>Priority: Minor
> Attachments: TestFlushSnapshotFromClient-2353.out,
> TestMobFlushSnapshotFromClient-2353.out, testSnapshotStateAfterMerge-2353.out
>
>
> On recent QA runs, TestMobFlushSnapshotFromClient failed twice.
> https://builds.apache.org/job/PreCommit-HBASE-Build/2360/#showFailuresLink
> https://builds.apache.org/job/PreCommit-HBASE-Build/2353/artifact/patchprocess/patch-unit-hbase-server.txt
> {code}
> org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient.org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient
> Run 1:
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.tearDown:123->Object.wait:-2
> » TestTimedOut
> Run 2:
> TestMobFlushSnapshotFromClient.org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient
> »
> org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient.testSnapshotStateAfterMerge(org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient)
> Run 1:
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.testSnapshotStateAfterMerge:335->TestFlushSnapshotFromClient.waitRegionsAfterMerge:526
> » RetriesExhausted
> Run 2:
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.tearDown:123 »
> InterruptedIO
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16931) Setting cell's seqId to zero in compaction flow might cause RS down.
[
https://issues.apache.org/jira/browse/HBASE-16931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605578#comment-15605578
]
Hudson commented on HBASE-16931:
FAILURE: Integrated in Jenkins build HBase-1.1-JDK8 #1888 (See
[https://builds.apache.org/job/HBase-1.1-JDK8/1888/])
HBASE-16931 Setting cell's seqId to zero in compaction flow might cause (liyu:
rev f4cbf77f28a2668743b1c73b5aeb113c3456fb13)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/Compactor.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompaction.java
> Setting cell's seqId to zero in compaction flow might cause RS down.
>
>
> Key: HBASE-16931
> URL: https://issues.apache.org/jira/browse/HBASE-16931
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: binlijin
>Assignee: binlijin
>Priority: Critical
> Fix For: 2.0.0, 1.4.0, 1.2.4, 1.1.8
>
> Attachments: HBASE-16931-master.patch, HBASE-16931.branch-1.patch,
> HBASE-16931.branch-1.v2.patch, HBASE-16931_master_v2.patch,
> HBASE-16931_master_v3.patch, HBASE-16931_master_v4.patch,
> HBASE-16931_master_v5.patch
>
>
> Compactor#performCompaction
> do {
> hasMore = scanner.next(cells, scannerContext);
> // output to writer:
> for (Cell c : cells) {
> if (cleanSeqId && c.getSequenceId() <= smallestReadPoint) {
> CellUtil.setSequenceId(c, 0);
> }
> writer.append(c);
> }
> cells.clear();
> } while (hasMore);
> scanner.next will choose at most "hbase.hstore.compaction.kv.max" kvs, the
> last cell still reference by StoreScanner.prevCell, so if cleanSeqId is
> called when the scanner.next call StoreScanner.checkScanOrder may throw
> exception and cause regionserver down.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16783) Use ByteBufferPool for the header and message during Rpc response
[ https://issues.apache.org/jira/browse/HBASE-16783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605571#comment-15605571 ] stack commented on HBASE-16783: --- LGTM > Use ByteBufferPool for the header and message during Rpc response > - > > Key: HBASE-16783 > URL: https://issues.apache.org/jira/browse/HBASE-16783 > Project: HBase > Issue Type: Improvement >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Attachments: HBASE-16783.patch, HBASE-16783_1.patch, > HBASE-16783_2.patch, HBASE-16783_3.patch, HBASE-16783_4.patch, > HBASE-16783_5.patch, HBASE-16783_6.patch, HBASE-16783_7.patch > > > With ByteBufferPool in place we could avoid the byte[] creation in > RpcServer#createHeaderAndMessageBytes and try using the Buffer from the pool > rather than creating byte[] every time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16841) Data loss in MOB files after cloning a snapshot and deleting that snapshot
[
https://issues.apache.org/jira/browse/HBASE-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605412#comment-15605412
]
Ted Yu commented on HBASE-16841:
Patch v3 is good by me.
> Data loss in MOB files after cloning a snapshot and deleting that snapshot
> --
>
> Key: HBASE-16841
> URL: https://issues.apache.org/jira/browse/HBASE-16841
> Project: HBase
> Issue Type: Bug
> Components: mob, snapshots
>Reporter: Jingcheng Du
>Assignee: Jingcheng Du
> Attachments: HBASE-16841-V2.patch, HBASE-16841-V3.patch,
> HBASE-16841.patch
>
>
> Running the following steps will probably lose MOB data when working with
> snapshots.
> 1. Create a mob-enabled table by running create 't1', {NAME => 'f1', IS_MOB
> => true, MOB_THRESHOLD => 0}.
> 2. Put millions of data.
> 3. Run {{snapshot 't1','t1_snapshot'}} to take a snapshot for this table t1.
> 4. Run {{clone_snapshot 't1_snapshot','t1_cloned'}} to clone this snapshot.
> 5. Run {{delete_snapshot 't1_snapshot'}} to delete this snapshot.
> 6. Run {{disable 't1'}} and {{delete 't1'}} to delete the table.
> 7. Now go to the archive directory of t1, the number of .link directories is
> different from the number of hfiles which means some data will be lost after
> the hfile cleaner runs.
> This is because, when taking a snapshot on a enabled mob table, each region
> flushes itself and takes a snapshot, and the mob snapshot is taken only if
> the current region is first region of the table. At that time, the flushing
> of some regions might not be finished, and some mob files are not flushed to
> disk yet. Eventually some mob files are not recorded in the snapshot manifest.
> To solve this, we need to take the mob snapshot at last after the snapshots
> on all the online and offline regions are finished in
> {{EnabledTableSnapshotHandler}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16910) Avoid NPE when starting StochasticLoadBalancer
[
https://issues.apache.org/jira/browse/HBASE-16910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605451#comment-15605451
]
Hudson commented on HBASE-16910:
SUCCESS: Integrated in Jenkins build HBase-1.4 #495 (See
[https://builds.apache.org/job/HBase-1.4/495/])
HBASE-16910 Avoid NPE when starting StochasticLoadBalancer (ashishsinghi: rev
ae502a9d5ce3dc5c4a485c3ff364d433bdf29a10)
* (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/StochasticLoadBalancer.java
> Avoid NPE when starting StochasticLoadBalancer
> --
>
> Key: HBASE-16910
> URL: https://issues.apache.org/jira/browse/HBASE-16910
> Project: HBase
> Issue Type: Bug
> Components: Balancer
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-16910-branch-1.patch, HBASE-16910-v1.patch,
> HBASE-16910.patch
>
>
> When master start, it initialize StochasticLoadBalancer.
> {code}
> this.balancer.setClusterStatus(getClusterStatus());
> this.balancer.setMasterServices(this);
> {code}
> It first setClusterStatus(), then setMasterService(). But in setClusterStatus
> method, it use master service which is not initialized. So it will throw NPE.
> {code}
> int tablesCount = isByTable ? services.getTableDescriptors().getAll().size()
> : 1;
> {code}
> It happens when set isByTable is ture.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14551) Procedure v2 - Reimplement split
[ https://issues.apache.org/jira/browse/HBASE-14551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-14551: --- Hadoop Flags: Reviewed Status: Patch Available (was: Open) > Procedure v2 - Reimplement split > > > Key: HBASE-14551 > URL: https://issues.apache.org/jira/browse/HBASE-14551 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Stephen Yuan Jiang >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-14551.v1-master.patch > > > use the proc-v2 state machine for split. also update the logic to have a > single meta-writer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14551) Procedure v2 - Reimplement split
[ https://issues.apache.org/jira/browse/HBASE-14551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-14551: --- Attachment: HBASE-14551.v1-master.patch > Procedure v2 - Reimplement split > > > Key: HBASE-14551 > URL: https://issues.apache.org/jira/browse/HBASE-14551 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Stephen Yuan Jiang >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-14551.v1-master.patch > > > use the proc-v2 state machine for split. also update the logic to have a > single meta-writer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
