[jira] [Commented] (HBASE-21172) Reimplement the retry backoff logic for ReopenTableRegionsProcedure
[ https://issues.apache.org/jira/browse/HBASE-21172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608378#comment-16608378 ] Hadoop QA commented on HBASE-21172: --- | (/) *{color:green}+1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 12s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 0s{color} | {color:green} Patch does not have any anti-patterns. {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 2 new or modified test files. {color} | || || || || {color:brown} master Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 24s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m 0s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 4s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 24s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m 9s{color} | {color:green} branch has no errors when building our shaded downstream artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 26s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 43s{color} | {color:green} master passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 14s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m 54s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 4s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 4s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 14s{color} | {color:green} hbase-procedure: The patch generated 0 new + 1 unchanged - 2 fixed = 1 total (was 3) {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 10s{color} | {color:green} The patch hbase-server passed checkstyle {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m 15s{color} | {color:green} patch has no errors when building our shaded downstream artifacts. {color} | | {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 10m 24s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 34s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 43s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 52s{color} | {color:green} hbase-procedure in the patch passed. {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green}119m 43s{color} | {color:green} hbase-server in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 39s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black}166m 47s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b | | JIRA Issue | HBASE-21172 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12938980/HBASE-21172-v1.patch | | Optional Tests | asflicense javac javadoc unit findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux fc8ad10e0929 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27 10:45:36 UTC 2018 x86_64 GNU/Linux | | Build tool | maven | | Personality | /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-B
[jira] [Updated] (HBASE-21173) Remove the duplicate HRegion#close in TestHRegion
[ https://issues.apache.org/jira/browse/HBASE-21173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guangxu Cheng updated HBASE-21173: -- Attachment: HBASE-21173.master.002.patch > Remove the duplicate HRegion#close in TestHRegion > - > > Key: HBASE-21173 > URL: https://issues.apache.org/jira/browse/HBASE-21173 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 3.0.0, 2.2.0 >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Major > Attachments: HBASE-21173.master.001.patch, > HBASE-21173.master.002.patch > > > After HBASE-21138, some test methods still have the duplicate > HRegion#close.So open this issue to remove the duplicate close -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21173) Remove the duplicate HRegion#close in TestHRegion
[ https://issues.apache.org/jira/browse/HBASE-21173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608389#comment-16608389 ] Guangxu Cheng commented on HBASE-21173: --- Attach 002 patch as [~yuzhih...@gmail.com] [~liuml07] suggestions.Thanks {{testSequenceId}} - In line 269, Replace region.close() with HBaseTestingUtility.closeRegionAndWAL(region) - In line 285, we need to verify that the value of region.getMaxFlushedSeqId() is consistent before and after region.close(), so we keep region.close() and replace it with HBaseTestingUtility.closeRegionAndWAL(region). {{testCloseCarryingSnapshot}} - In line 315, replace region.close() with HBaseTestingUtility.closeRegionAndWAL(region) - In line 317, remove duplicate HBaseTestingUtility.closeRegionAndWAL(region) and set this.region to null {{testCloseWithFailingFlush}} - In line 578, replace region.close() with HBaseTestingUtility.closeRegionAndWAL(region) and set this.region to null {{testRecoveredEditsReplayCompaction}} - In line 951, replace region.close() with HBaseTestingUtility.closeRegionAndWAL(region) {{testFlushMarkers}} - In line 1083, replace region.close() with HBaseTestingUtility.closeRegionAndWAL(region) {{testGetWhileRegionClose}} - In line 1281, set this.region to null {{testBatchPut_whileMultipleRowLocksHeld}} - In line 1281, set this.region to null {{testRegionInfoFileCreation}} - In line 4175, keep region.close() and set region to null as said by Mingliang Liu {{testBulkLoadReplicationEnabled}} - In line 6234, remove region.close() {quote}Other places to set this.region null value after HTU.closeRegionAndWAL() is good to explicitly make the HTU.closeRegionAndWAL() in tearDown a no-op. {quote} Other places where set this.region null value after HTU.closeRegionAndWAL(), will be fine as said by [~liuml07]. > Remove the duplicate HRegion#close in TestHRegion > - > > Key: HBASE-21173 > URL: https://issues.apache.org/jira/browse/HBASE-21173 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 3.0.0, 2.2.0 >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Major > Attachments: HBASE-21173.master.001.patch, > HBASE-21173.master.002.patch > > > After HBASE-21138, some test methods still have the duplicate > HRegion#close.So open this issue to remove the duplicate close -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21158) Empty qualifier cell is always returned when using QualifierFilter
[ https://issues.apache.org/jira/browse/HBASE-21158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608390#comment-16608390 ] Guangxu Cheng commented on HBASE-21158: --- I will commit it tomorrow if no other comments. Thanks > Empty qualifier cell is always returned when using QualifierFilter > -- > > Key: HBASE-21158 > URL: https://issues.apache.org/jira/browse/HBASE-21158 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 3.0.0, 2.2.0 >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Major > Attachments: HBASE-21158.master.001.patch, > HBASE-21158.master.002.patch > > > {code:xml} > hbase(main):002:0> put 'testTable','testrow','f:testcol1','testvalue1' > 0 row(s) in 0.0040 seconds > hbase(main):003:0> put 'testTable','testrow','f:','testvalue2' > 0 row(s) in 0.0070 seconds > # get row with empty column f:, result is correct. > hbase(main):004:0> scan 'testTable',{FILTER => "QualifierFilter (=, > 'binary:')"} > ROW COLUMN+CELL > > > testrowcolumn=f:, > timestamp=1536218563581, value=testvalue2 > > 1 row(s) in 0.0460 seconds > # get row with column f:testcol1, result is incorrect. > hbase(main):005:0> scan 'testTable',{FILTER => "QualifierFilter (=, > 'binary:testcol1')"} > ROW COLUMN+CELL > > > testrowcolumn=f:, > timestamp=1536218563581, value=testvalue2 > > testrowcolumn=f:testcol1, > timestamp=1536218550827, value=testvalue1 > > 1 row(s) in 0.0070 seconds > {code} > As the above operation, when the row contains empty qualifier column, empty > qualifier cell is always returned when using QualifierFilter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21174) [REST] Failed to parse empty qualifier in TableResource#getScanResource
Guangxu Cheng created HBASE-21174: - Summary: [REST] Failed to parse empty qualifier in TableResource#getScanResource Key: HBASE-21174 URL: https://issues.apache.org/jira/browse/HBASE-21174 Project: HBase Issue Type: Bug Components: REST Affects Versions: 3.0.0, 2.2.0 Environment: {code:xml} GET /t1/*?column=f:c1&column=f: {code} If I want to get the values of 'f:'(empty qualifier) for all rows in the table by rest server, I will send the above request. However, this request will return all column values. {code:java|title=TableResource#getScanResource|borderStyle=solid} for (String csplit : column) { String[] familysplit = csplit.trim().split(":"); if (familysplit.length == 2) { if (familysplit[1].length() > 0) { if (LOG.isTraceEnabled()) { LOG.trace("Scan family and column : " + familysplit[0] + " " + familysplit[1]); } tableScan.addColumn(Bytes.toBytes(familysplit[0]), Bytes.toBytes(familysplit[1])); } else { tableScan.addFamily(Bytes.toBytes(familysplit[0])); if (LOG.isTraceEnabled()) { LOG.trace("Scan family : " + familysplit[0] + " and empty qualifier."); } tableScan.addColumn(Bytes.toBytes(familysplit[0]), null); } } else if (StringUtils.isNotEmpty(familysplit[0])) { if (LOG.isTraceEnabled()) { LOG.trace("Scan family : " + familysplit[0]); } tableScan.addFamily(Bytes.toBytes(familysplit[0])); } } {code} Through the above code, when the column has an empty qualifier, the empty qualifier cannot be parsed correctly.In other words, 'f:'(empty qualifier) and 'f' (column family) are considered to have the same meaning, which is wrong. Reporter: Guangxu Cheng Assignee: Guangxu Cheng {code:title=TableResource#getScanResource|borderStyle=solid} for (String csplit : column) { String[] familysplit = csplit.trim().split(":"); if (familysplit.length == 2) { if (familysplit[1].length() > 0) { if (LOG.isTraceEnabled()) { LOG.trace("Scan family and column : " + familysplit[0] + " " + familysplit[1]); } tableScan.addColumn(Bytes.toBytes(familysplit[0]), Bytes.toBytes(familysplit[1])); } else { tableScan.addFamily(Bytes.toBytes(familysplit[0])); if (LOG.isTraceEnabled()) { LOG.trace("Scan family : " + familysplit[0] + " and empty qualifier."); } tableScan.addColumn(Bytes.toBytes(familysplit[0]), null); } } else if (StringUtils.isNotEmpty(familysplit[0])) { if (LOG.isTraceEnabled()) { LOG.trace("Scan family : " + familysplit[0]); } tableScan.addFamily(Bytes.toBytes(familysplit[0])); } } {code} {code:xml} GET /t1/*?column=f:c1&column=f: {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21174) [REST] Failed to parse empty qualifier in TableResource#getScanResource
[ https://issues.apache.org/jira/browse/HBASE-21174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guangxu Cheng updated HBASE-21174: -- Description: {code:xml} GET /t1/*?column=f:c1&column=f: {code} If I want to get the values of 'f:'(empty qualifier) for all rows in the table by rest server, I will send the above request. However, this request will return all column values. {code:java|title=TableResource#getScanResource|borderStyle=solid} for (String csplit : column) { String[] familysplit = csplit.trim().split(":"); if (familysplit.length == 2) { if (familysplit[1].length() > 0) { if (LOG.isTraceEnabled()) { LOG.trace("Scan family and column : " + familysplit[0] + " " + familysplit[1]); } tableScan.addColumn(Bytes.toBytes(familysplit[0]), Bytes.toBytes(familysplit[1])); } else { tableScan.addFamily(Bytes.toBytes(familysplit[0])); if (LOG.isTraceEnabled()) { LOG.trace("Scan family : " + familysplit[0] + " and empty qualifier."); } tableScan.addColumn(Bytes.toBytes(familysplit[0]), null); } } else if (StringUtils.isNotEmpty(familysplit[0])) { if (LOG.isTraceEnabled()) { LOG.trace("Scan family : " + familysplit[0]); } tableScan.addFamily(Bytes.toBytes(familysplit[0])); } } {code} Through the above code, when the column has an empty qualifier, the empty qualifier cannot be parsed correctly.In other words, 'f:'(empty qualifier) and 'f' (column family) are considered to have the same meaning, which is wrong. was: {code:title=TableResource#getScanResource|borderStyle=solid} for (String csplit : column) { String[] familysplit = csplit.trim().split(":"); if (familysplit.length == 2) { if (familysplit[1].length() > 0) { if (LOG.isTraceEnabled()) { LOG.trace("Scan family and column : " + familysplit[0] + " " + familysplit[1]); } tableScan.addColumn(Bytes.toBytes(familysplit[0]), Bytes.toBytes(familysplit[1])); } else { tableScan.addFamily(Bytes.toBytes(familysplit[0])); if (LOG.isTraceEnabled()) { LOG.trace("Scan family : " + familysplit[0] + " and empty qualifier."); } tableScan.addColumn(Bytes.toBytes(familysplit[0]), null); } } else if (StringUtils.isNotEmpty(familysplit[0])) { if (LOG.isTraceEnabled()) { LOG.trace("Scan family : " + familysplit[0]); } tableScan.addFamily(Bytes.toBytes(familysplit[0])); } } {code} {code:xml} GET /t1/*?column=f:c1&column=f: {code} > [REST] Failed to parse empty qualifier in TableResource#getScanResource > --- > > Key: HBASE-21174 > URL: https://issues.apache.org/jira/browse/HBASE-21174 > Project: HBase > Issue Type: Bug > Components: REST >Affects Versions: 3.0.0, 2.2.0 >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Major > > {code:xml} > GET /t1/*?column=f:c1&column=f: > {code} > If I want to get the values of 'f:'(empty qualifier) for all rows in the > table by rest server, I will send the above request. However, this request > will return all column values. > {code:java|title=TableResource#getScanResource|borderStyle=solid} > for (String csplit : column) { > String[] familysplit = csplit.trim().split(":"); > if (familysplit.length == 2) { > if (familysplit[1].length() > 0) { > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family and column : " + familysplit[0] + " " + > familysplit[1]); > } > tableScan.addColumn(Bytes.toBytes(familysplit[0]), > Bytes.toBytes(familysplit[1])); > } else { > tableScan.addFamily(Bytes.toBytes(familysplit[0])); > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family : " + familysplit[0] + " and empty > qualifier."); > } > tableScan.addColumn(Bytes.toBytes(familysplit[0]), null); > } > } else if (StringUtils.isNotEmpty(familysplit[0])) { > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family : " + familysplit[0]); > } > tableScan.addFamily(Bytes.toBytes(familysplit[0])); > } > } > {code} > Through the above code, when the column has an empty qualifier, the empty > qualifier cannot be parsed correctly.In other words, 'f:'(empty qualifier) > and 'f' (column family) are considered to have the same meaning, which is > wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21174) [REST] Failed to parse empty qualifier in TableResource#getScanResource
[ https://issues.apache.org/jira/browse/HBASE-21174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guangxu Cheng updated HBASE-21174: -- Environment: (was: {code:xml} GET /t1/*?column=f:c1&column=f: {code} If I want to get the values of 'f:'(empty qualifier) for all rows in the table by rest server, I will send the above request. However, this request will return all column values. {code:java|title=TableResource#getScanResource|borderStyle=solid} for (String csplit : column) { String[] familysplit = csplit.trim().split(":"); if (familysplit.length == 2) { if (familysplit[1].length() > 0) { if (LOG.isTraceEnabled()) { LOG.trace("Scan family and column : " + familysplit[0] + " " + familysplit[1]); } tableScan.addColumn(Bytes.toBytes(familysplit[0]), Bytes.toBytes(familysplit[1])); } else { tableScan.addFamily(Bytes.toBytes(familysplit[0])); if (LOG.isTraceEnabled()) { LOG.trace("Scan family : " + familysplit[0] + " and empty qualifier."); } tableScan.addColumn(Bytes.toBytes(familysplit[0]), null); } } else if (StringUtils.isNotEmpty(familysplit[0])) { if (LOG.isTraceEnabled()) { LOG.trace("Scan family : " + familysplit[0]); } tableScan.addFamily(Bytes.toBytes(familysplit[0])); } } {code} Through the above code, when the column has an empty qualifier, the empty qualifier cannot be parsed correctly.In other words, 'f:'(empty qualifier) and 'f' (column family) are considered to have the same meaning, which is wrong.) > [REST] Failed to parse empty qualifier in TableResource#getScanResource > --- > > Key: HBASE-21174 > URL: https://issues.apache.org/jira/browse/HBASE-21174 > Project: HBase > Issue Type: Bug > Components: REST >Affects Versions: 3.0.0, 2.2.0 >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Major > > {code:title=TableResource#getScanResource|borderStyle=solid} > for (String csplit : column) { > String[] familysplit = csplit.trim().split(":"); > if (familysplit.length == 2) { > if (familysplit[1].length() > 0) { > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family and column : " + familysplit[0] + " " + > familysplit[1]); > } > tableScan.addColumn(Bytes.toBytes(familysplit[0]), > Bytes.toBytes(familysplit[1])); > } else { > tableScan.addFamily(Bytes.toBytes(familysplit[0])); > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family : " + familysplit[0] + " and empty > qualifier."); > } > tableScan.addColumn(Bytes.toBytes(familysplit[0]), null); > } > } else if (StringUtils.isNotEmpty(familysplit[0])) { > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family : " + familysplit[0]); > } > tableScan.addFamily(Bytes.toBytes(familysplit[0])); > } > } > {code} > {code:xml} > GET /t1/*?column=f:c1&column=f: > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21174) [REST] Failed to parse empty qualifier in TableResource#getScanResource
[ https://issues.apache.org/jira/browse/HBASE-21174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guangxu Cheng updated HBASE-21174: -- Attachment: HBASE-21174.master.001.patch > [REST] Failed to parse empty qualifier in TableResource#getScanResource > --- > > Key: HBASE-21174 > URL: https://issues.apache.org/jira/browse/HBASE-21174 > Project: HBase > Issue Type: Bug > Components: REST >Affects Versions: 3.0.0, 2.2.0 >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Major > Attachments: HBASE-21174.master.001.patch > > > {code:xml} > GET /t1/*?column=f:c1&column=f: > {code} > If I want to get the values of 'f:'(empty qualifier) for all rows in the > table by rest server, I will send the above request. However, this request > will return all column values. > {code:java|title=TableResource#getScanResource|borderStyle=solid} > for (String csplit : column) { > String[] familysplit = csplit.trim().split(":"); > if (familysplit.length == 2) { > if (familysplit[1].length() > 0) { > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family and column : " + familysplit[0] + " " + > familysplit[1]); > } > tableScan.addColumn(Bytes.toBytes(familysplit[0]), > Bytes.toBytes(familysplit[1])); > } else { > tableScan.addFamily(Bytes.toBytes(familysplit[0])); > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family : " + familysplit[0] + " and empty > qualifier."); > } > tableScan.addColumn(Bytes.toBytes(familysplit[0]), null); > } > } else if (StringUtils.isNotEmpty(familysplit[0])) { > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family : " + familysplit[0]); > } > tableScan.addFamily(Bytes.toBytes(familysplit[0])); > } > } > {code} > Through the above code, when the column has an empty qualifier, the empty > qualifier cannot be parsed correctly.In other words, 'f:'(empty qualifier) > and 'f' (column family) are considered to have the same meaning, which is > wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21174) [REST] Failed to parse empty qualifier in TableResource#getScanResource
[ https://issues.apache.org/jira/browse/HBASE-21174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608419#comment-16608419 ] Guangxu Cheng commented on HBASE-21174: --- Attach first patch for review. Due to HBASE-21158, the new unit test for this issue will cause other unit tests to fail. So, after HBASE-21158 is fixed and then trigger QA. > [REST] Failed to parse empty qualifier in TableResource#getScanResource > --- > > Key: HBASE-21174 > URL: https://issues.apache.org/jira/browse/HBASE-21174 > Project: HBase > Issue Type: Bug > Components: REST >Affects Versions: 3.0.0, 2.2.0 >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Major > Attachments: HBASE-21174.master.001.patch > > > {code:xml} > GET /t1/*?column=f:c1&column=f: > {code} > If I want to get the values of 'f:'(empty qualifier) for all rows in the > table by rest server, I will send the above request. However, this request > will return all column values. > {code:java|title=TableResource#getScanResource|borderStyle=solid} > for (String csplit : column) { > String[] familysplit = csplit.trim().split(":"); > if (familysplit.length == 2) { > if (familysplit[1].length() > 0) { > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family and column : " + familysplit[0] + " " + > familysplit[1]); > } > tableScan.addColumn(Bytes.toBytes(familysplit[0]), > Bytes.toBytes(familysplit[1])); > } else { > tableScan.addFamily(Bytes.toBytes(familysplit[0])); > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family : " + familysplit[0] + " and empty > qualifier."); > } > tableScan.addColumn(Bytes.toBytes(familysplit[0]), null); > } > } else if (StringUtils.isNotEmpty(familysplit[0])) { > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family : " + familysplit[0]); > } > tableScan.addFamily(Bytes.toBytes(familysplit[0])); > } > } > {code} > Through the above code, when the column has an empty qualifier, the empty > qualifier cannot be parsed correctly.In other words, 'f:'(empty qualifier) > and 'f' (column family) are considered to have the same meaning, which is > wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21173) Remove the duplicate HRegion#close in TestHRegion
[ https://issues.apache.org/jira/browse/HBASE-21173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608428#comment-16608428 ] Hadoop QA commented on HBASE-21173: --- | (/) *{color:green}+1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 13s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 0s{color} | {color:green} Patch does not have any anti-patterns. {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 1 new or modified test files. {color} | || || || || {color:brown} master Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m 54s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 11s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 20s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m 49s{color} | {color:green} branch has no errors when building our shaded downstream artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 27s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 39s{color} | {color:green} master passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m 47s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 3s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 3s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 20s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m 45s{color} | {color:green} patch has no errors when building our shaded downstream artifacts. {color} | | {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 12m 1s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 34s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green}126m 55s{color} | {color:green} hbase-server in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 20s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black}174m 30s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b | | JIRA Issue | HBASE-21173 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12938986/HBASE-21173.master.002.patch | | Optional Tests | asflicense javac javadoc unit findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux 739b275a2df0 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27 10:45:36 UTC 2018 x86_64 GNU/Linux | | Build tool | maven | | Personality | /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh | | git revision | master / a51c333856 | | maven | version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC3 | | Test Results | https://builds.apache.org/job/PreCommit-HBASE-Build/14370/testReport/ | | Max. process+thread count | 4395 (vs. ulimit of 1) | | modules | C: hbase-server U: hbase-server | | Console output | https://builds.apache.org/job/PreCommit-HBASE-Build/14370/console | | Powered by | Apache Yetus 0.7.0 http://yetus.apache.org | This message was automatically generated. > Remove the du
[jira] [Commented] (HBASE-21052) After restoring a snapshot, table.jsp page for the table gets stuck
[ https://issues.apache.org/jira/browse/HBASE-21052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608442#comment-16608442 ] Hudson commented on HBASE-21052: Results for branch master [build #482 on builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/482/]: (x) *{color:red}-1 overall{color}* details (if available): (/) {color:green}+1 general checks{color} -- For more information [see general report|https://builds.apache.org/job/HBase%20Nightly/job/master/482//General_Nightly_Build_Report/] (x) {color:red}-1 jdk8 hadoop2 checks{color} -- For more information [see jdk8 (hadoop2) report|https://builds.apache.org/job/HBase%20Nightly/job/master/482//JDK8_Nightly_Build_Report_(Hadoop2)/] (x) {color:red}-1 jdk8 hadoop3 checks{color} -- For more information [see jdk8 (hadoop3) report|https://builds.apache.org/job/HBase%20Nightly/job/master/482//JDK8_Nightly_Build_Report_(Hadoop3)/] (/) {color:green}+1 source release artifact{color} -- See build output for details. (/) {color:green}+1 client integration test{color} > After restoring a snapshot, table.jsp page for the table gets stuck > --- > > Key: HBASE-21052 > URL: https://issues.apache.org/jira/browse/HBASE-21052 > Project: HBase > Issue Type: Bug > Components: snapshots >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-21052.master.001.patch, > HBASE-21052.master.002.patch, HBASE-21052.master.003.patch > > > Steps to reproduce are as follows: > 1. Create a table > {code} > create "test", "cf" > {code} > 2. Take a hbase snapshot for the table > {code} > snapshot "test", "snap" > {code} > 3. Disable the table > {code} > disable "test" > {code} > 4. Restore the hbase snapshot > {code} > restore_snapshot "snap" > {code} > 5. Open the table.jsp page for the table in a browser, but it gets stuck > {code} > http://:16010/table.jsp?name=test > {code} > According to the following thread dump, it looks like > ConnectionImplementation.locateRegionInMeta() gets stuck when getting a > compaction state. > {code} > "qtp2068100669-89" #89 daemon prio=5 os_prio=31 tid=0x7febac55b800 > nid=0xf403 waiting on condition [0x762b7000] >java.lang.Thread.State: TIMED_WAITING (sleeping) > at java.lang.Thread.sleep(Native Method) > at > org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegionInMeta(ConnectionImplementation.java:933) > at > org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:752) > at > org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131) > at > org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:738) > at > org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131) > at > org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegions(ConnectionImplementation.java:694) > at > org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegions(ConnectionUtils.java:131) > at > org.apache.hadoop.hbase.client.HBaseAdmin.getCompactionState(HBaseAdmin.java:3336) > at > org.apache.hadoop.hbase.client.HBaseAdmin.getCompactionState(HBaseAdmin.java:2521) > at > org.apache.hadoop.hbase.generated.master.table_jsp._jspService(table_jsp.java:316) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:840) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1772) > at > org.apache.hadoop.hbase.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:112) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759) > at > org.apache.hadoop.hbase.http.ClickjackingPreventionFilter.doFilter(ClickjackingPreventionFilter.java:48) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759) > at > org.apache.hadoop.hbase.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:1374) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759) > at > org.apache.hadoop.hbase.http.NoCacheFilter.doFilter(NoCacheFilter.java:49) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759) >
[jira] [Commented] (HBASE-16458) Shorten backup / restore test execution time
[ https://issues.apache.org/jira/browse/HBASE-16458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608468#comment-16608468 ] Mike Drob commented on HBASE-16458: --- I'd like to review this patch but I'm confused which file I should be looking at. Use of shutdown hooks caught my attention and is generally inadvisable. > Shorten backup / restore test execution time > > > Key: HBASE-16458 > URL: https://issues.apache.org/jira/browse/HBASE-16458 > Project: HBase > Issue Type: Test >Reporter: Ted Yu >Assignee: Vladimir Rodionov >Priority: Major > Labels: backup > Attachments: 16458-v1.patch, 16458.HBASE-7912.v3.txt, > 16458.HBASE-7912.v4.txt, 16458.HBASE-7912.v5.txt, 16458.v1.txt, 16458.v2.txt, > 16458.v2.txt, 16458.v3.txt, 16458.v4.txt, 16458.v5.txt, HBASE-16458-v1.patch, > HBASE-16458-v2.patch > > > Below was timing information for all the backup / restore tests (today's > result): > {code} > Running org.apache.hadoop.hbase.backup.TestIncrementalBackup > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 576.273 sec - > in org.apache.hadoop.hbase.backup.TestIncrementalBackup > Running org.apache.hadoop.hbase.backup.TestBackupBoundaryTests > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 124.67 sec - > in org.apache.hadoop.hbase.backup.TestBackupBoundaryTests > Running org.apache.hadoop.hbase.backup.TestBackupStatusProgress > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 102.34 sec - > in org.apache.hadoop.hbase.backup.TestBackupStatusProgress > Running org.apache.hadoop.hbase.backup.TestBackupAdmin > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 490.251 sec - > in org.apache.hadoop.hbase.backup.TestBackupAdmin > Running org.apache.hadoop.hbase.backup.TestHFileArchiving > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.323 sec - > in org.apache.hadoop.hbase.backup.TestHFileArchiving > Running org.apache.hadoop.hbase.backup.TestSystemTableSnapshot > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.492 sec - > in org.apache.hadoop.hbase.backup.TestSystemTableSnapshot > Running org.apache.hadoop.hbase.backup.TestBackupDescribe > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 93.758 sec - > in org.apache.hadoop.hbase.backup.TestBackupDescribe > Running org.apache.hadoop.hbase.backup.TestBackupLogCleaner > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 109.187 sec - > in org.apache.hadoop.hbase.backup.TestBackupLogCleaner > Running org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 330.539 sec - > in org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss > Running org.apache.hadoop.hbase.backup.TestRemoteBackup > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.371 sec - > in org.apache.hadoop.hbase.backup.TestRemoteBackup > Running org.apache.hadoop.hbase.backup.TestBackupSystemTable > Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 67.893 sec - > in org.apache.hadoop.hbase.backup.TestBackupSystemTable > Running org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 120.779 sec - > in org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests > Running org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 117.815 sec - > in org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet > Running org.apache.hadoop.hbase.backup.TestBackupShowHistory > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 136.517 sec - > in org.apache.hadoop.hbase.backup.TestBackupShowHistory > Running org.apache.hadoop.hbase.backup.TestRemoteRestore > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.799 sec - > in org.apache.hadoop.hbase.backup.TestRemoteRestore > Running org.apache.hadoop.hbase.backup.TestFullRestore > Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 317.711 sec > - in org.apache.hadoop.hbase.backup.TestFullRestore > Running org.apache.hadoop.hbase.backup.TestFullBackupSet > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 87.045 sec - > in org.apache.hadoop.hbase.backup.TestFullBackupSet > Running org.apache.hadoop.hbase.backup.TestBackupDelete > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 86.214 sec - > in org.apache.hadoop.hbase.backup.TestBackupDelete > Running org.apache.hadoop.hbase.backup.TestBackupDeleteRestore > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 77.631 sec - > in org.apache.hadoop.hbase.backup.TestBackupDeleteRestore > Running org.apache.hadoop.hbase.backup.
[jira] [Commented] (HBASE-21174) [REST] Failed to parse empty qualifier in TableResource#getScanResource
[ https://issues.apache.org/jira/browse/HBASE-21174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608469#comment-16608469 ] Ted Yu commented on HBASE-21174: +1, pending QA > [REST] Failed to parse empty qualifier in TableResource#getScanResource > --- > > Key: HBASE-21174 > URL: https://issues.apache.org/jira/browse/HBASE-21174 > Project: HBase > Issue Type: Bug > Components: REST >Affects Versions: 3.0.0, 2.2.0 >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Major > Attachments: HBASE-21174.master.001.patch > > > {code:xml} > GET /t1/*?column=f:c1&column=f: > {code} > If I want to get the values of 'f:'(empty qualifier) for all rows in the > table by rest server, I will send the above request. However, this request > will return all column values. > {code:java|title=TableResource#getScanResource|borderStyle=solid} > for (String csplit : column) { > String[] familysplit = csplit.trim().split(":"); > if (familysplit.length == 2) { > if (familysplit[1].length() > 0) { > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family and column : " + familysplit[0] + " " + > familysplit[1]); > } > tableScan.addColumn(Bytes.toBytes(familysplit[0]), > Bytes.toBytes(familysplit[1])); > } else { > tableScan.addFamily(Bytes.toBytes(familysplit[0])); > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family : " + familysplit[0] + " and empty > qualifier."); > } > tableScan.addColumn(Bytes.toBytes(familysplit[0]), null); > } > } else if (StringUtils.isNotEmpty(familysplit[0])) { > if (LOG.isTraceEnabled()) { > LOG.trace("Scan family : " + familysplit[0]); > } > tableScan.addFamily(Bytes.toBytes(familysplit[0])); > } > } > {code} > Through the above code, when the column has an empty qualifier, the empty > qualifier cannot be parsed correctly.In other words, 'f:'(empty qualifier) > and 'f' (column family) are considered to have the same meaning, which is > wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-16458) Shorten backup / restore test execution time
[ https://issues.apache.org/jira/browse/HBASE-16458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-16458: --- Attachment: (was: 16458.HBASE-7912.v5.txt) > Shorten backup / restore test execution time > > > Key: HBASE-16458 > URL: https://issues.apache.org/jira/browse/HBASE-16458 > Project: HBase > Issue Type: Test >Reporter: Ted Yu >Assignee: Vladimir Rodionov >Priority: Major > Labels: backup > Attachments: 16458-v1.patch, 16458.HBASE-7912.v3.txt, > 16458.HBASE-7912.v4.txt, 16458.v1.txt, 16458.v2.txt, 16458.v2.txt, > 16458.v3.txt, 16458.v4.txt, 16458.v5.txt, HBASE-16458-v1.patch, > HBASE-16458-v2.patch > > > Below was timing information for all the backup / restore tests (today's > result): > {code} > Running org.apache.hadoop.hbase.backup.TestIncrementalBackup > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 576.273 sec - > in org.apache.hadoop.hbase.backup.TestIncrementalBackup > Running org.apache.hadoop.hbase.backup.TestBackupBoundaryTests > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 124.67 sec - > in org.apache.hadoop.hbase.backup.TestBackupBoundaryTests > Running org.apache.hadoop.hbase.backup.TestBackupStatusProgress > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 102.34 sec - > in org.apache.hadoop.hbase.backup.TestBackupStatusProgress > Running org.apache.hadoop.hbase.backup.TestBackupAdmin > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 490.251 sec - > in org.apache.hadoop.hbase.backup.TestBackupAdmin > Running org.apache.hadoop.hbase.backup.TestHFileArchiving > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.323 sec - > in org.apache.hadoop.hbase.backup.TestHFileArchiving > Running org.apache.hadoop.hbase.backup.TestSystemTableSnapshot > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.492 sec - > in org.apache.hadoop.hbase.backup.TestSystemTableSnapshot > Running org.apache.hadoop.hbase.backup.TestBackupDescribe > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 93.758 sec - > in org.apache.hadoop.hbase.backup.TestBackupDescribe > Running org.apache.hadoop.hbase.backup.TestBackupLogCleaner > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 109.187 sec - > in org.apache.hadoop.hbase.backup.TestBackupLogCleaner > Running org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 330.539 sec - > in org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss > Running org.apache.hadoop.hbase.backup.TestRemoteBackup > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.371 sec - > in org.apache.hadoop.hbase.backup.TestRemoteBackup > Running org.apache.hadoop.hbase.backup.TestBackupSystemTable > Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 67.893 sec - > in org.apache.hadoop.hbase.backup.TestBackupSystemTable > Running org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 120.779 sec - > in org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests > Running org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 117.815 sec - > in org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet > Running org.apache.hadoop.hbase.backup.TestBackupShowHistory > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 136.517 sec - > in org.apache.hadoop.hbase.backup.TestBackupShowHistory > Running org.apache.hadoop.hbase.backup.TestRemoteRestore > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.799 sec - > in org.apache.hadoop.hbase.backup.TestRemoteRestore > Running org.apache.hadoop.hbase.backup.TestFullRestore > Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 317.711 sec > - in org.apache.hadoop.hbase.backup.TestFullRestore > Running org.apache.hadoop.hbase.backup.TestFullBackupSet > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 87.045 sec - > in org.apache.hadoop.hbase.backup.TestFullBackupSet > Running org.apache.hadoop.hbase.backup.TestBackupDelete > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 86.214 sec - > in org.apache.hadoop.hbase.backup.TestBackupDelete > Running org.apache.hadoop.hbase.backup.TestBackupDeleteRestore > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 77.631 sec - > in org.apache.hadoop.hbase.backup.TestBackupDeleteRestore > Running org.apache.hadoop.hbase.backup.TestIncrementalBackupDeleteTable > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 190.358 sec - > in org.apache.hadoop.hbase.backup.TestIncrementalBackupDeleteTable > Running
[jira] [Commented] (HBASE-16458) Shorten backup / restore test execution time
[ https://issues.apache.org/jira/browse/HBASE-16458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608470#comment-16608470 ] Ted Yu commented on HBASE-16458: HBASE-16458-v2.patch was the last one from Vlad. Patch v5 is from me. > Shorten backup / restore test execution time > > > Key: HBASE-16458 > URL: https://issues.apache.org/jira/browse/HBASE-16458 > Project: HBase > Issue Type: Test >Reporter: Ted Yu >Assignee: Vladimir Rodionov >Priority: Major > Labels: backup > Attachments: 16458-v1.patch, 16458.HBASE-7912.v3.txt, > 16458.HBASE-7912.v4.txt, 16458.v1.txt, 16458.v2.txt, 16458.v2.txt, > 16458.v3.txt, 16458.v4.txt, 16458.v5.txt, HBASE-16458-v1.patch, > HBASE-16458-v2.patch > > > Below was timing information for all the backup / restore tests (today's > result): > {code} > Running org.apache.hadoop.hbase.backup.TestIncrementalBackup > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 576.273 sec - > in org.apache.hadoop.hbase.backup.TestIncrementalBackup > Running org.apache.hadoop.hbase.backup.TestBackupBoundaryTests > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 124.67 sec - > in org.apache.hadoop.hbase.backup.TestBackupBoundaryTests > Running org.apache.hadoop.hbase.backup.TestBackupStatusProgress > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 102.34 sec - > in org.apache.hadoop.hbase.backup.TestBackupStatusProgress > Running org.apache.hadoop.hbase.backup.TestBackupAdmin > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 490.251 sec - > in org.apache.hadoop.hbase.backup.TestBackupAdmin > Running org.apache.hadoop.hbase.backup.TestHFileArchiving > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.323 sec - > in org.apache.hadoop.hbase.backup.TestHFileArchiving > Running org.apache.hadoop.hbase.backup.TestSystemTableSnapshot > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.492 sec - > in org.apache.hadoop.hbase.backup.TestSystemTableSnapshot > Running org.apache.hadoop.hbase.backup.TestBackupDescribe > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 93.758 sec - > in org.apache.hadoop.hbase.backup.TestBackupDescribe > Running org.apache.hadoop.hbase.backup.TestBackupLogCleaner > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 109.187 sec - > in org.apache.hadoop.hbase.backup.TestBackupLogCleaner > Running org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 330.539 sec - > in org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss > Running org.apache.hadoop.hbase.backup.TestRemoteBackup > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.371 sec - > in org.apache.hadoop.hbase.backup.TestRemoteBackup > Running org.apache.hadoop.hbase.backup.TestBackupSystemTable > Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 67.893 sec - > in org.apache.hadoop.hbase.backup.TestBackupSystemTable > Running org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 120.779 sec - > in org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests > Running org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 117.815 sec - > in org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet > Running org.apache.hadoop.hbase.backup.TestBackupShowHistory > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 136.517 sec - > in org.apache.hadoop.hbase.backup.TestBackupShowHistory > Running org.apache.hadoop.hbase.backup.TestRemoteRestore > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.799 sec - > in org.apache.hadoop.hbase.backup.TestRemoteRestore > Running org.apache.hadoop.hbase.backup.TestFullRestore > Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 317.711 sec > - in org.apache.hadoop.hbase.backup.TestFullRestore > Running org.apache.hadoop.hbase.backup.TestFullBackupSet > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 87.045 sec - > in org.apache.hadoop.hbase.backup.TestFullBackupSet > Running org.apache.hadoop.hbase.backup.TestBackupDelete > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 86.214 sec - > in org.apache.hadoop.hbase.backup.TestBackupDelete > Running org.apache.hadoop.hbase.backup.TestBackupDeleteRestore > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 77.631 sec - > in org.apache.hadoop.hbase.backup.TestBackupDeleteRestore > Running org.apache.hadoop.hbase.backup.TestIncrementalBackupDeleteTable > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 190.358 sec - >
[jira] [Updated] (HBASE-21171) [amv2] Tool to parse a directory of MasterProcWALs standalone
[ https://issues.apache.org/jira/browse/HBASE-21171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-21171: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.1.1 2.2.0 3.0.0 Status: Resolved (was: Patch Available) Pushed to branch-2.1. Thanks for review. > [amv2] Tool to parse a directory of MasterProcWALs standalone > - > > Key: HBASE-21171 > URL: https://issues.apache.org/jira/browse/HBASE-21171 > Project: HBase > Issue Type: Bug > Components: amv2, test >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1 > > Attachments: HBASE-21171.branch-2.1.001.patch, > HBASE-21171.branch-2.1.002.patch, HBASE-21171.branch-2.1.003.patch > > > I want to be able to test parsing and be able to profile a standalone parse > and WALProcedureStore load of procedures. Adding a simple main on > WALProcedureStore seems to be enough. I tested parsing it a dir of hundreds > of WALs to see what is going on when we try to load. Good for figuring how to > log, where the memory is going, etc., in this subsystem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-16458) Shorten backup / restore test execution time
[ https://issues.apache.org/jira/browse/HBASE-16458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608470#comment-16608470 ] Ted Yu edited comment on HBASE-16458 at 9/9/18 4:29 PM: HBASE-16458-v2.patch was the last one from Vlad. Patch v5 is from me, based on Vlad's v2. was (Author: yuzhih...@gmail.com): HBASE-16458-v2.patch was the last one from Vlad. Patch v5 is from me. > Shorten backup / restore test execution time > > > Key: HBASE-16458 > URL: https://issues.apache.org/jira/browse/HBASE-16458 > Project: HBase > Issue Type: Test >Reporter: Ted Yu >Assignee: Vladimir Rodionov >Priority: Major > Labels: backup > Attachments: 16458-v1.patch, 16458.HBASE-7912.v3.txt, > 16458.HBASE-7912.v4.txt, 16458.v1.txt, 16458.v2.txt, 16458.v2.txt, > 16458.v3.txt, 16458.v4.txt, 16458.v5.txt, HBASE-16458-v1.patch, > HBASE-16458-v2.patch > > > Below was timing information for all the backup / restore tests (today's > result): > {code} > Running org.apache.hadoop.hbase.backup.TestIncrementalBackup > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 576.273 sec - > in org.apache.hadoop.hbase.backup.TestIncrementalBackup > Running org.apache.hadoop.hbase.backup.TestBackupBoundaryTests > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 124.67 sec - > in org.apache.hadoop.hbase.backup.TestBackupBoundaryTests > Running org.apache.hadoop.hbase.backup.TestBackupStatusProgress > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 102.34 sec - > in org.apache.hadoop.hbase.backup.TestBackupStatusProgress > Running org.apache.hadoop.hbase.backup.TestBackupAdmin > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 490.251 sec - > in org.apache.hadoop.hbase.backup.TestBackupAdmin > Running org.apache.hadoop.hbase.backup.TestHFileArchiving > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.323 sec - > in org.apache.hadoop.hbase.backup.TestHFileArchiving > Running org.apache.hadoop.hbase.backup.TestSystemTableSnapshot > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.492 sec - > in org.apache.hadoop.hbase.backup.TestSystemTableSnapshot > Running org.apache.hadoop.hbase.backup.TestBackupDescribe > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 93.758 sec - > in org.apache.hadoop.hbase.backup.TestBackupDescribe > Running org.apache.hadoop.hbase.backup.TestBackupLogCleaner > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 109.187 sec - > in org.apache.hadoop.hbase.backup.TestBackupLogCleaner > Running org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 330.539 sec - > in org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss > Running org.apache.hadoop.hbase.backup.TestRemoteBackup > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.371 sec - > in org.apache.hadoop.hbase.backup.TestRemoteBackup > Running org.apache.hadoop.hbase.backup.TestBackupSystemTable > Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 67.893 sec - > in org.apache.hadoop.hbase.backup.TestBackupSystemTable > Running org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 120.779 sec - > in org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests > Running org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 117.815 sec - > in org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet > Running org.apache.hadoop.hbase.backup.TestBackupShowHistory > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 136.517 sec - > in org.apache.hadoop.hbase.backup.TestBackupShowHistory > Running org.apache.hadoop.hbase.backup.TestRemoteRestore > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.799 sec - > in org.apache.hadoop.hbase.backup.TestRemoteRestore > Running org.apache.hadoop.hbase.backup.TestFullRestore > Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 317.711 sec > - in org.apache.hadoop.hbase.backup.TestFullRestore > Running org.apache.hadoop.hbase.backup.TestFullBackupSet > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 87.045 sec - > in org.apache.hadoop.hbase.backup.TestFullBackupSet > Running org.apache.hadoop.hbase.backup.TestBackupDelete > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 86.214 sec - > in org.apache.hadoop.hbase.backup.TestBackupDelete > Running org.apache.hadoop.hbase.backup.TestBackupDeleteRestore > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 77.631 sec - > in org.apache.hadoop.hbase.backup.TestB
[jira] [Commented] (HBASE-16458) Shorten backup / restore test execution time
[ https://issues.apache.org/jira/browse/HBASE-16458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608533#comment-16608533 ] Vladimir Rodionov commented on HBASE-16458: --- [~ted_yu], cleanup must be done after *all* unit tests. Just *mvn clean* should work fine. > Shorten backup / restore test execution time > > > Key: HBASE-16458 > URL: https://issues.apache.org/jira/browse/HBASE-16458 > Project: HBase > Issue Type: Test >Reporter: Ted Yu >Assignee: Vladimir Rodionov >Priority: Major > Labels: backup > Attachments: 16458-v1.patch, 16458.HBASE-7912.v3.txt, > 16458.HBASE-7912.v4.txt, 16458.v1.txt, 16458.v2.txt, 16458.v2.txt, > 16458.v3.txt, 16458.v4.txt, 16458.v5.txt, HBASE-16458-v1.patch, > HBASE-16458-v2.patch > > > Below was timing information for all the backup / restore tests (today's > result): > {code} > Running org.apache.hadoop.hbase.backup.TestIncrementalBackup > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 576.273 sec - > in org.apache.hadoop.hbase.backup.TestIncrementalBackup > Running org.apache.hadoop.hbase.backup.TestBackupBoundaryTests > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 124.67 sec - > in org.apache.hadoop.hbase.backup.TestBackupBoundaryTests > Running org.apache.hadoop.hbase.backup.TestBackupStatusProgress > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 102.34 sec - > in org.apache.hadoop.hbase.backup.TestBackupStatusProgress > Running org.apache.hadoop.hbase.backup.TestBackupAdmin > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 490.251 sec - > in org.apache.hadoop.hbase.backup.TestBackupAdmin > Running org.apache.hadoop.hbase.backup.TestHFileArchiving > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.323 sec - > in org.apache.hadoop.hbase.backup.TestHFileArchiving > Running org.apache.hadoop.hbase.backup.TestSystemTableSnapshot > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.492 sec - > in org.apache.hadoop.hbase.backup.TestSystemTableSnapshot > Running org.apache.hadoop.hbase.backup.TestBackupDescribe > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 93.758 sec - > in org.apache.hadoop.hbase.backup.TestBackupDescribe > Running org.apache.hadoop.hbase.backup.TestBackupLogCleaner > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 109.187 sec - > in org.apache.hadoop.hbase.backup.TestBackupLogCleaner > Running org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 330.539 sec - > in org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss > Running org.apache.hadoop.hbase.backup.TestRemoteBackup > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.371 sec - > in org.apache.hadoop.hbase.backup.TestRemoteBackup > Running org.apache.hadoop.hbase.backup.TestBackupSystemTable > Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 67.893 sec - > in org.apache.hadoop.hbase.backup.TestBackupSystemTable > Running org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 120.779 sec - > in org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests > Running org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 117.815 sec - > in org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet > Running org.apache.hadoop.hbase.backup.TestBackupShowHistory > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 136.517 sec - > in org.apache.hadoop.hbase.backup.TestBackupShowHistory > Running org.apache.hadoop.hbase.backup.TestRemoteRestore > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.799 sec - > in org.apache.hadoop.hbase.backup.TestRemoteRestore > Running org.apache.hadoop.hbase.backup.TestFullRestore > Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 317.711 sec > - in org.apache.hadoop.hbase.backup.TestFullRestore > Running org.apache.hadoop.hbase.backup.TestFullBackupSet > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 87.045 sec - > in org.apache.hadoop.hbase.backup.TestFullBackupSet > Running org.apache.hadoop.hbase.backup.TestBackupDelete > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 86.214 sec - > in org.apache.hadoop.hbase.backup.TestBackupDelete > Running org.apache.hadoop.hbase.backup.TestBackupDeleteRestore > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 77.631 sec - > in org.apache.hadoop.hbase.backup.TestBackupDeleteRestore > Running org.apache.hadoop.hbase.backup.TestIncrementalBackupDeleteTable > Tests run: 1, Failures: 0, Errors: 0,
[jira] [Updated] (HBASE-21150) Avoid delay in first flushes due to overheads in table metrics registration
[ https://issues.apache.org/jira/browse/HBASE-21150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-21150: --- Attachment: (was: 21150.v7.txt) > Avoid delay in first flushes due to overheads in table metrics registration > --- > > Key: HBASE-21150 > URL: https://issues.apache.org/jira/browse/HBASE-21150 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Priority: Minor > Attachments: 21150.v1.txt, 21150.v2.txt, 21150.v3.txt, 21150.v4.txt, > 21150.v4.txt, 21150.v5.txt > > > After HBASE-15728 is integrated, the lazy table metrics registration results > in penalty for the first flushes. > Excerpt from log shows delay (note the same timestamp 08:18:23,234) : > {code:java} > 2018-09-02 08:18:23,232 DEBUG > [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2] > regionserver.MetricsTableSourceImpl(124): Creating new > MetricsTableSourceImpl for table 'testtb-1535901500805' > 2018-09-02 08:18:23,233 DEBUG > [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2] > regionserver.MetricsTableSourceImpl(137): registering metrics for testtb- > 1535901500805 > 2018-09-02 08:18:23,234 INFO > [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-1] > regionserver.HRegion(2822): Finished flush of dataSize ~2.29 KB/2343, > heapSize ~5.16 KB/5280, currentSize=0 B/0 for > fa403f6a4fb8dbc1a1c389744fce2d58 in 280ms, sequenceid=5, compaction > requested=false > 2018-09-02 08:18:23,234 DEBUG > [rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-1] > regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register > testtb-1535901500805 > Thread[rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-1,5,FailOnTimeoutGroup] > 2018-09-02 08:18:23,234 DEBUG > [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-1] > regionserver.MetricsTableAggregateSourceImpl(84): it took 0 ms to register > testtb-1535901500805 > Thread[rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-1,5,FailOnTimeoutGroup] > 2018-09-02 08:18:23,234 DEBUG > [rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-1] > regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register > testtb-1535901500805 > Thread[rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-1,5,FailOnTimeoutGroup] > 2018-09-02 08:18:23,234 DEBUG > [rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-2] > regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register > testtb-1535901500805 > Thread[rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-2,5,FailOnTimeoutGroup] > 2018-09-02 08:18:23,234 DEBUG > [rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-2] > regionserver.MetricsTableAggregateSourceImpl(84): it took 5 ms to register > testtb-1535901500805 > Thread[rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-2,5,FailOnTimeoutGroup] > 2018-09-02 08:18:23,234 DEBUG > [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2] > regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register > testtb-1535901500805 > Thread[rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2,5,FailOnTimeoutGroup] > {code} > This is a regression in that there were multiple (6 ms) delays before the > flush can finish, waiting for the metrics table to be registered. > When first region of the table is opened on region server, we can proactively > register table metrics. > This would avoid the penalty on first flushes for the table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21150) Avoid delay in first flushes due to overheads in table metrics registration
[ https://issues.apache.org/jira/browse/HBASE-21150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-21150: --- Attachment: (was: 21150.v6.txt) > Avoid delay in first flushes due to overheads in table metrics registration > --- > > Key: HBASE-21150 > URL: https://issues.apache.org/jira/browse/HBASE-21150 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Priority: Minor > Attachments: 21150.v1.txt, 21150.v2.txt, 21150.v3.txt, 21150.v4.txt, > 21150.v4.txt, 21150.v5.txt > > > After HBASE-15728 is integrated, the lazy table metrics registration results > in penalty for the first flushes. > Excerpt from log shows delay (note the same timestamp 08:18:23,234) : > {code:java} > 2018-09-02 08:18:23,232 DEBUG > [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2] > regionserver.MetricsTableSourceImpl(124): Creating new > MetricsTableSourceImpl for table 'testtb-1535901500805' > 2018-09-02 08:18:23,233 DEBUG > [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2] > regionserver.MetricsTableSourceImpl(137): registering metrics for testtb- > 1535901500805 > 2018-09-02 08:18:23,234 INFO > [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-1] > regionserver.HRegion(2822): Finished flush of dataSize ~2.29 KB/2343, > heapSize ~5.16 KB/5280, currentSize=0 B/0 for > fa403f6a4fb8dbc1a1c389744fce2d58 in 280ms, sequenceid=5, compaction > requested=false > 2018-09-02 08:18:23,234 DEBUG > [rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-1] > regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register > testtb-1535901500805 > Thread[rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-1,5,FailOnTimeoutGroup] > 2018-09-02 08:18:23,234 DEBUG > [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-1] > regionserver.MetricsTableAggregateSourceImpl(84): it took 0 ms to register > testtb-1535901500805 > Thread[rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-1,5,FailOnTimeoutGroup] > 2018-09-02 08:18:23,234 DEBUG > [rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-1] > regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register > testtb-1535901500805 > Thread[rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-1,5,FailOnTimeoutGroup] > 2018-09-02 08:18:23,234 DEBUG > [rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-2] > regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register > testtb-1535901500805 > Thread[rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-2,5,FailOnTimeoutGroup] > 2018-09-02 08:18:23,234 DEBUG > [rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-2] > regionserver.MetricsTableAggregateSourceImpl(84): it took 5 ms to register > testtb-1535901500805 > Thread[rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-2,5,FailOnTimeoutGroup] > 2018-09-02 08:18:23,234 DEBUG > [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2] > regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register > testtb-1535901500805 > Thread[rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2,5,FailOnTimeoutGroup] > {code} > This is a regression in that there were multiple (6 ms) delays before the > flush can finish, waiting for the metrics table to be registered. > When first region of the table is opened on region server, we can proactively > register table metrics. > This would avoid the penalty on first flushes for the table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21171) [amv2] Tool to parse a directory of MasterProcWALs standalone
[ https://issues.apache.org/jira/browse/HBASE-21171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608586#comment-16608586 ] Hudson commented on HBASE-21171: Results for branch branch-2.1 [build #302 on builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/302/]: (x) *{color:red}-1 overall{color}* details (if available): (/) {color:green}+1 general checks{color} -- For more information [see general report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/302//General_Nightly_Build_Report/] (x) {color:red}-1 jdk8 hadoop2 checks{color} -- For more information [see jdk8 (hadoop2) report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/302//JDK8_Nightly_Build_Report_(Hadoop2)/] (x) {color:red}-1 jdk8 hadoop3 checks{color} -- For more information [see jdk8 (hadoop3) report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/302//JDK8_Nightly_Build_Report_(Hadoop3)/] (/) {color:green}+1 source release artifact{color} -- See build output for details. (/) {color:green}+1 client integration test{color} > [amv2] Tool to parse a directory of MasterProcWALs standalone > - > > Key: HBASE-21171 > URL: https://issues.apache.org/jira/browse/HBASE-21171 > Project: HBase > Issue Type: Bug > Components: amv2, test >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1 > > Attachments: HBASE-21171.branch-2.1.001.patch, > HBASE-21171.branch-2.1.002.patch, HBASE-21171.branch-2.1.003.patch > > > I want to be able to test parsing and be able to profile a standalone parse > and WALProcedureStore load of procedures. Adding a simple main on > WALProcedureStore seems to be enough. I tested parsing it a dir of hundreds > of WALs to see what is going on when we try to load. Good for figuring how to > log, where the memory is going, etc., in this subsystem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21171) [amv2] Tool to parse a directory of MasterProcWALs standalone
[ https://issues.apache.org/jira/browse/HBASE-21171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608590#comment-16608590 ] Hudson commented on HBASE-21171: Results for branch branch-2 [build #1226 on builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1226/]: (x) *{color:red}-1 overall{color}* details (if available): (/) {color:green}+1 general checks{color} -- For more information [see general report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1226//General_Nightly_Build_Report/] (x) {color:red}-1 jdk8 hadoop2 checks{color} -- For more information [see jdk8 (hadoop2) report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1226//JDK8_Nightly_Build_Report_(Hadoop2)/] (/) {color:green}+1 jdk8 hadoop3 checks{color} -- For more information [see jdk8 (hadoop3) report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1226//JDK8_Nightly_Build_Report_(Hadoop3)/] (/) {color:green}+1 source release artifact{color} -- See build output for details. (/) {color:green}+1 client integration test{color} > [amv2] Tool to parse a directory of MasterProcWALs standalone > - > > Key: HBASE-21171 > URL: https://issues.apache.org/jira/browse/HBASE-21171 > Project: HBase > Issue Type: Bug > Components: amv2, test >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1 > > Attachments: HBASE-21171.branch-2.1.001.patch, > HBASE-21171.branch-2.1.002.patch, HBASE-21171.branch-2.1.003.patch > > > I want to be able to test parsing and be able to profile a standalone parse > and WALProcedureStore load of procedures. Adding a simple main on > WALProcedureStore seems to be enough. I tested parsing it a dir of hundreds > of WALs to see what is going on when we try to load. Good for figuring how to > log, where the memory is going, etc., in this subsystem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21175) Partially initialized SnapshotHFileCleaner leads to NPE during TestHFileArchiving
Ted Yu created HBASE-21175: -- Summary: Partially initialized SnapshotHFileCleaner leads to NPE during TestHFileArchiving Key: HBASE-21175 URL: https://issues.apache.org/jira/browse/HBASE-21175 Project: HBase Issue Type: Test Reporter: Ted Yu TestHFileArchiving#testCleaningRace creates HFileCleaner instance within the test. When SnapshotHFileCleaner.init() is called, there is no master parameter passed in {{params}}. When the chore runs the cleaner during the test, NPE comes out of this line in getDeletableFiles(): {code} return cache.getUnreferencedFiles(files, master.getSnapshotManager()); {code} since master is null. We should either check for the null master or, pass master instance properly when constructing the cleaner instance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21176) HBase 2.0.1, several inconsistency issues
Oleg Galitskiy created HBASE-21176: -- Summary: HBase 2.0.1, several inconsistency issues Key: HBASE-21176 URL: https://issues.apache.org/jira/browse/HBASE-21176 Project: HBase Issue Type: Bug Reporter: Oleg Galitskiy Faced with several inconsistency issues in HBase 2.0.1: {code} ERROR: Region \{ meta => null, hdfs => hdfs://master:50001/hbase/data/default/some_table/0646d0bee757d0fb0de1529475b5426f, deployed => hbase-region,16020,1536493017073;some_table,,1534195327532.0646d0bee757d0fb0de1529475b5426f., replicaId => 0 } not in META, but deployed on hbase-region,16020,1536493017073 ... ERROR: hbase:namespace has no state in meta ERROR: table1 has no state in meta ERROR: table2 has no state in meta 2018-09-09 21:40:04,155 INFO [main] util.HBaseFsck: Handling overlap merges in parallel. set hbasefsck.overlap.merge.parallel to false to run serially. ERROR: There is a hole in the region chain between and . You need to create a new .regioninfo and region dir in hdfs to plug the hole. ERROR: Found inconsistency in table test3 {code} BUT in 2.0.x HBAse version options _-repair, -fix, -fixHdfsHoles, etc_ was deprecated. How I can fix it without these options? Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21159) Add shell command to switch throttle on or off
[ https://issues.apache.org/jira/browse/HBASE-21159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Mei updated HBASE-21159: --- Attachment: HBASE-21159.master.001.patch > Add shell command to switch throttle on or off > -- > > Key: HBASE-21159 > URL: https://issues.apache.org/jira/browse/HBASE-21159 > Project: HBase > Issue Type: Sub-task >Affects Versions: 3.0.0, 2.2.0 >Reporter: Yi Mei >Priority: Major > Attachments: HBASE-21159.master.001.patch > > > Add shell command to switch throttle on or off. When throttle is off, HBase > will not throttle any request. This feature may be useful in production > environment. > We can use the following commands to switch throttle: > throttle_switch true / throttle_switch false -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HBASE-21159) Add shell command to switch throttle on or off
[ https://issues.apache.org/jira/browse/HBASE-21159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Mei reassigned HBASE-21159: -- Assignee: Yi Mei > Add shell command to switch throttle on or off > -- > > Key: HBASE-21159 > URL: https://issues.apache.org/jira/browse/HBASE-21159 > Project: HBase > Issue Type: Sub-task >Affects Versions: 3.0.0, 2.2.0 >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > Attachments: HBASE-21159.master.001.patch > > > Add shell command to switch throttle on or off. When throttle is off, HBase > will not throttle any request. This feature may be useful in production > environment. > We can use the following commands to switch throttle: > throttle_switch true / throttle_switch false -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21159) Add shell command to switch throttle on or off
[ https://issues.apache.org/jira/browse/HBASE-21159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608630#comment-16608630 ] Yi Mei commented on HBASE-21159: Hi [~xucang], it's a good idea to use "enable_throttle" / "disable_throttle". Thanks for your suggestions. > Add shell command to switch throttle on or off > -- > > Key: HBASE-21159 > URL: https://issues.apache.org/jira/browse/HBASE-21159 > Project: HBase > Issue Type: Sub-task >Affects Versions: 3.0.0, 2.2.0 >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > Attachments: HBASE-21159.master.001.patch > > > Add shell command to switch throttle on or off. When throttle is off, HBase > will not throttle any request. This feature may be useful in production > environment. > We can use the following commands to switch throttle: > throttle_switch true / throttle_switch false -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21177) Add per-table metrics on getTime,putTime and scanTime
xijiawen created HBASE-21177: Summary: Add per-table metrics on getTime,putTime and scanTime Key: HBASE-21177 URL: https://issues.apache.org/jira/browse/HBASE-21177 Project: HBase Issue Type: New Feature Components: metrics Affects Versions: 2.0.2 Reporter: xijiawen Fix For: HBASE-14850 Adds getTime,putTime,SscanTime to the per-table mertrics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21172) Reimplement the retry backoff logic for ReopenTableRegionsProcedure
[ https://issues.apache.org/jira/browse/HBASE-21172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21172: -- Attachment: HBASE-21172-v2.patch > Reimplement the retry backoff logic for ReopenTableRegionsProcedure > --- > > Key: HBASE-21172 > URL: https://issues.apache.org/jira/browse/HBASE-21172 > Project: HBase > Issue Type: Sub-task > Components: amv2, proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3 > > Attachments: HBASE-21172-v1.patch, HBASE-21172-v2.patch, > HBASE-21172.patch > > > Now we just do a blocking sleep in the execute method, and there is no > exponential backoff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21144) AssignmentManager.waitForAssignment is not stable
[ https://issues.apache.org/jira/browse/HBASE-21144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21144: -- Attachment: HBASE-21144-branch-2.1.patch > AssignmentManager.waitForAssignment is not stable > - > > Key: HBASE-21144 > URL: https://issues.apache.org/jira/browse/HBASE-21144 > Project: HBase > Issue Type: Bug > Components: amv2, test >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3 > > Attachments: HBASE-21144-addendum.patch, > HBASE-21144-branch-2.1.patch, HBASE-21144-v1.patch, HBASE-21144.patch > > > https://builds.apache.org/job/HBase-Flaky-Tests/job/master/366/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestMetaWithReplicas-output.txt/*view*/ > All replicas for meta table are on the same machine > {noformat} > 2018-09-02 19:49:05,486 DEBUG [RS_OPEN_META-regionserver/asf904:0-0] > handler.OpenRegionHandler(127): Opened hbase:meta,,1.1588230740 on > asf904.gq1.ygridcore.net,47561,1535917740998 > 2018-09-02 19:49:32,802 DEBUG [RS_OPEN_META-regionserver/asf904:0-0] > handler.OpenRegionHandler(127): Opened hbase:meta,,1_0001.534574363 on > asf904.gq1.ygridcore.net,55408,1535917768453 > 2018-09-02 19:49:33,496 DEBUG [RS_OPEN_META-regionserver/asf904:0-0] > handler.OpenRegionHandler(127): Opened hbase:meta,,1_0002.1657623790 on > asf904.gq1.ygridcore.net,55408,1535917768453 > {noformat} > But after calling am.waitForAssignment, the region location is still null... > {noformat} > 2018-09-02 19:49:32,414 INFO [Time-limited test] > client.TestMetaWithReplicas(113): HBASE:META DEPLOY: > hbase:meta,,1_0001.534574363 on null > 2018-09-02 19:49:32,844 INFO [Time-limited test] > client.TestMetaWithReplicas(113): HBASE:META DEPLOY: > hbase:meta,,1_0002.1657623790 on null > {noformat} > So we will not balance the replicas and cause TestMetaWithReplicas to hang > forever... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21144) AssignmentManager.waitForAssignment is not stable
[ https://issues.apache.org/jira/browse/HBASE-21144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21144: -- Attachment: HBASE-21172-v3.patch > AssignmentManager.waitForAssignment is not stable > - > > Key: HBASE-21144 > URL: https://issues.apache.org/jira/browse/HBASE-21144 > Project: HBase > Issue Type: Bug > Components: amv2, test >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3 > > Attachments: HBASE-21144-addendum.patch, > HBASE-21144-branch-2.1.patch, HBASE-21144-v1.patch, HBASE-21144.patch > > > https://builds.apache.org/job/HBase-Flaky-Tests/job/master/366/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestMetaWithReplicas-output.txt/*view*/ > All replicas for meta table are on the same machine > {noformat} > 2018-09-02 19:49:05,486 DEBUG [RS_OPEN_META-regionserver/asf904:0-0] > handler.OpenRegionHandler(127): Opened hbase:meta,,1.1588230740 on > asf904.gq1.ygridcore.net,47561,1535917740998 > 2018-09-02 19:49:32,802 DEBUG [RS_OPEN_META-regionserver/asf904:0-0] > handler.OpenRegionHandler(127): Opened hbase:meta,,1_0001.534574363 on > asf904.gq1.ygridcore.net,55408,1535917768453 > 2018-09-02 19:49:33,496 DEBUG [RS_OPEN_META-regionserver/asf904:0-0] > handler.OpenRegionHandler(127): Opened hbase:meta,,1_0002.1657623790 on > asf904.gq1.ygridcore.net,55408,1535917768453 > {noformat} > But after calling am.waitForAssignment, the region location is still null... > {noformat} > 2018-09-02 19:49:32,414 INFO [Time-limited test] > client.TestMetaWithReplicas(113): HBASE:META DEPLOY: > hbase:meta,,1_0001.534574363 on null > 2018-09-02 19:49:32,844 INFO [Time-limited test] > client.TestMetaWithReplicas(113): HBASE:META DEPLOY: > hbase:meta,,1_0002.1657623790 on null > {noformat} > So we will not balance the replicas and cause TestMetaWithReplicas to hang > forever... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21144) AssignmentManager.waitForAssignment is not stable
[ https://issues.apache.org/jira/browse/HBASE-21144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21144: -- Attachment: (was: HBASE-21172-v3.patch) > AssignmentManager.waitForAssignment is not stable > - > > Key: HBASE-21144 > URL: https://issues.apache.org/jira/browse/HBASE-21144 > Project: HBase > Issue Type: Bug > Components: amv2, test >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3 > > Attachments: HBASE-21144-addendum.patch, > HBASE-21144-branch-2.1.patch, HBASE-21144-v1.patch, HBASE-21144.patch > > > https://builds.apache.org/job/HBase-Flaky-Tests/job/master/366/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestMetaWithReplicas-output.txt/*view*/ > All replicas for meta table are on the same machine > {noformat} > 2018-09-02 19:49:05,486 DEBUG [RS_OPEN_META-regionserver/asf904:0-0] > handler.OpenRegionHandler(127): Opened hbase:meta,,1.1588230740 on > asf904.gq1.ygridcore.net,47561,1535917740998 > 2018-09-02 19:49:32,802 DEBUG [RS_OPEN_META-regionserver/asf904:0-0] > handler.OpenRegionHandler(127): Opened hbase:meta,,1_0001.534574363 on > asf904.gq1.ygridcore.net,55408,1535917768453 > 2018-09-02 19:49:33,496 DEBUG [RS_OPEN_META-regionserver/asf904:0-0] > handler.OpenRegionHandler(127): Opened hbase:meta,,1_0002.1657623790 on > asf904.gq1.ygridcore.net,55408,1535917768453 > {noformat} > But after calling am.waitForAssignment, the region location is still null... > {noformat} > 2018-09-02 19:49:32,414 INFO [Time-limited test] > client.TestMetaWithReplicas(113): HBASE:META DEPLOY: > hbase:meta,,1_0001.534574363 on null > 2018-09-02 19:49:32,844 INFO [Time-limited test] > client.TestMetaWithReplicas(113): HBASE:META DEPLOY: > hbase:meta,,1_0002.1657623790 on null > {noformat} > So we will not balance the replicas and cause TestMetaWithReplicas to hang > forever... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21172) Reimplement the retry backoff logic for ReopenTableRegionsProcedure
[ https://issues.apache.org/jira/browse/HBASE-21172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608703#comment-16608703 ] Duo Zhang commented on HBASE-21172: --- Typo. > Reimplement the retry backoff logic for ReopenTableRegionsProcedure > --- > > Key: HBASE-21172 > URL: https://issues.apache.org/jira/browse/HBASE-21172 > Project: HBase > Issue Type: Sub-task > Components: amv2, proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3 > > Attachments: HBASE-21172-v1.patch, HBASE-21172-v2.patch, > HBASE-21172-v3.patch, HBASE-21172.patch > > > Now we just do a blocking sleep in the execute method, and there is no > exponential backoff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21172) Reimplement the retry backoff logic for ReopenTableRegionsProcedure
[ https://issues.apache.org/jira/browse/HBASE-21172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21172: -- Attachment: HBASE-21172-v3.patch > Reimplement the retry backoff logic for ReopenTableRegionsProcedure > --- > > Key: HBASE-21172 > URL: https://issues.apache.org/jira/browse/HBASE-21172 > Project: HBase > Issue Type: Sub-task > Components: amv2, proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3 > > Attachments: HBASE-21172-v1.patch, HBASE-21172-v2.patch, > HBASE-21172-v3.patch, HBASE-21172.patch > > > Now we just do a blocking sleep in the execute method, and there is no > exponential backoff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21178) Get and Scan operation with converter_class not working
Subrat Mishra created HBASE-21178: - Summary: Get and Scan operation with converter_class not working Key: HBASE-21178 URL: https://issues.apache.org/jira/browse/HBASE-21178 Project: HBase Issue Type: Bug Reporter: Subrat Mishra Assignee: Subrat Mishra Consider a simple scenario: {code:java} create 'foo', {NAME => 'f1'} put 'foo','r1','f1:a',1000 get 'foo','r1',{COLUMNS => ['f1:a:c(org.apache.hadoop.hbase.util.Bytes).len']} scan 'foo',{COLUMNS => ['f1:a:c(org.apache.hadoop.hbase.util.Bytes).len']}{code} Both get and scan fails with ERROR {code:java} ERROR: wrong number of arguments (3 for 1) {code} Looks like in table.rb file converter_method expects 3 arguments [(bytes, offset, len)] since version 2.0.0, prior to version 2.0.0 it was taking only 1 argument [(bytes)] -- This message was sent by Atlassian JIRA (v7.6.3#76005)