[jira] [Commented] (HBASE-15104) Occasional failures due to NotServingRegionException in IT tests
[ https://issues.apache.org/jira/browse/HBASE-15104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101701#comment-15101701 ] Hudson commented on HBASE-15104: FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #1160 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/1160/]) HBASE-15104 Occasional failures due to NotServingRegionException in IT (jmhsieh: rev f46bee0a7dd0dd315d9681a63000ab3cfa716656) * hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/actions/ChangeCompressionAction.java > Occasional failures due to NotServingRegionException in IT tests > > > Key: HBASE-15104 > URL: https://issues.apache.org/jira/browse/HBASE-15104 > Project: HBase > Issue Type: Bug > Components: integration tests >Affects Versions: 1.2.0 >Reporter: huaxiang sun >Assignee: huaxiang sun > Fix For: 2.0.0, 0.94.28, 1.2.0, 1.1.3, 1.0.4 > > Attachments: HBASE-15104-v001.patch > > > IntegrationTestAcidGuarantees fails when trying to cleanup with > NotServerRegionExceptions giving up (after 36 attempts) . > 5/11/09 09:19:24 INFO client.AsyncProcess: #33, waiting for some tasks to > finish. Expected max=0, tasksInProgress=9 > 15/11/09 09:19:33 INFO client.AsyncProcess: #45, table=TestAcidGuarantees, > attempt=10/35 failed=1ops, last exception: > org.apache.hadoop.hbase.NotServingRegionException: > org.apache.hadoop.hbase.NotServingRegionException: Region > TestAcidGuarantees,test_row_1,1447089367019.032439ef4f3353cb894d20337ba043bc. > is not online on node-4.internal,22101,1447089152259 > at > org.apache.hadoop.hbase.regionserver.HRegionServer.getRegionByEncodedName(HRegionServer.java:2786) > at > org.apache.hadoop.hbase.regionserver.RSRpcServices.getRegion(RSRpcServices.java:922) > at > org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:1893) > at > org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32213) > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2035) > at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107) > at > org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130) > at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107) > at java.lang.Thread.run(Thread.java:745) > ... > Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed > after attempts=36, exceptions: > Mon Nov 09 09:19:53 PST 2015, null, java.net.SocketTimeoutException: > callTimeout=6, callDuration=68104: row 'test_row_1' > Looked at the RS log, the following exception is found: > 2015-11-10 10:07:49,091 ERROR > org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler: Failed open > of > region=TestAcidGuarantees,,1447177733243.f1be6b850fe3958c5c9b5e330b5dfb00., > starting to roll back the global memstore size. > org.apache.hadoop.hbase.DoNotRetryIOException: java.lang.RuntimeException: > java.lang.ClassNotFoundException: com.hadoop.compression.lzo.LzoCodec > at > org.apache.hadoop.hbase.util.CompressionTest.testCompression(CompressionTest.java:102) > at > org.apache.hadoop.hbase.regionserver.HRegion.checkCompressionCodecs(HRegion.java:6011) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5995) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5967) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5938) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5894) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5845) > at > org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:356) > at > org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:126) > at > org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:128) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15097) When the scan operation covered two regions,sometimes the final results have duplicated rows.
[
https://issues.apache.org/jira/browse/HBASE-15097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101715#comment-15101715
]
Hadoop QA commented on HBASE-15097:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
24s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 4s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
22s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 55s
{color} | {color:red} hbase-server in master has 83 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 55s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 48s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
7s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 57s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 57s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 5m 19s
{color} | {color:red} Patch generated 2 new checkstyle issues in hbase-server
(total was 294, now 296). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
19s {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 2 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
26m 51s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 5s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 97m 26s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 92m 7s {color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_79. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
13s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 243m 59s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0 Failed junit tests | hadoop.hbase.regionserver.TestHRegion |
| | hadoop.hbase.client.TestFromClientSide |
| | hadoop.hbase.util.TestHBaseFsckOneRS |
| | hadoop.hbase.client.TestFromClientSideWithCoprocessor |
| JDK v1.7.0_79 Failed junit tests | hadoop.hbase.regionserver.TestHRegion |
| | hadoop.hbase.client.TestFromClientSide |
| | hadoop.hbase.util.TestHBaseFsckOneRS |
| |
[jira] [Updated] (HBASE-13590) TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey
[ https://issues.apache.org/jira/browse/HBASE-13590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-13590: -- Attachment: testEnableTableHandler_branch-1.log.zip Attaching the 100x test result for branch-1, confirmed TestEnableTableHandler no more fails. 100x test for branch-1.1 is still in progress, will update later. According to current branch-1.1 result, have logged HBASE-15120 to fix TestSplitTransactionOnCluster failure > TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey > --- > > Key: HBASE-13590 > URL: https://issues.apache.org/jira/browse/HBASE-13590 > Project: HBase > Issue Type: Test > Components: master >Reporter: Nick Dimiduk >Assignee: Yu Li > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4 > > Attachments: HBASE-13590.branch-1.1.patch, > HBASE-13590.branch-1.patch, HBASE-13590.branch-1.v2.patch, > testEnableTableHandler_branch-1.log.zip > > > Looking at our [build > history|https://builds.apache.org/job/HBase-1.1/buildTimeTrend], it seems > this test is flakey. See builds 429, 431, 439. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15097) When the scan operation covered two regions,sometimes the final results have duplicated rows.
[
https://issues.apache.org/jira/browse/HBASE-15097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101706#comment-15101706
]
Hadoop QA commented on HBASE-15097:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
19s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
25s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 52s
{color} | {color:red} hbase-server in master has 83 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 31s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
42s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 31s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 31s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 7s
{color} | {color:red} Patch generated 2 new checkstyle issues in hbase-server
(total was 294, now 296). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {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 2 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 46s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 1s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 98m 7s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 103m 10s
{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_79.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
16s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 243m 3s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0 Failed junit tests | hadoop.hbase.util.TestHBaseFsckOneRS |
| | hadoop.hbase.regionserver.TestHRegion |
| | hadoop.hbase.client.TestFromClientSide |
| | hadoop.hbase.client.TestFromClientSideWithCoprocessor |
| JDK v1.7.0_79 Failed junit tests | hadoop.hbase.util.TestHBaseFsckOneRS |
| | hadoop.hbase.regionserver.TestHRegion |
| | hadoop.hbase.client.TestFromClientSide |
| |
[jira] [Updated] (HBASE-15120) Backport HBASE-14883 to branch-1.1
[ https://issues.apache.org/jira/browse/HBASE-15120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-15120: -- Attachment: HBASE-15120.branch-1.1.patch A straight forward patch > Backport HBASE-14883 to branch-1.1 > -- > > Key: HBASE-15120 > URL: https://issues.apache.org/jira/browse/HBASE-15120 > Project: HBase > Issue Type: Bug >Affects Versions: 1.1.2 >Reporter: Yu Li >Assignee: Yu Li >Priority: Minor > Attachments: HBASE-15120.branch-1.1.patch > > > When checking branch-1.1 UT in HBASE-13590, found > TestSplitTransactionOnCluster#testFailedSplit will fail at a 12/50 chance. > The issue is fixed by HBASE-14883 but the change didn't go into branch-1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15120) Backport HBASE-14883 to branch-1.1
[ https://issues.apache.org/jira/browse/HBASE-15120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-15120: -- Status: Patch Available (was: Open) Submit for HadoopQA > Backport HBASE-14883 to branch-1.1 > -- > > Key: HBASE-15120 > URL: https://issues.apache.org/jira/browse/HBASE-15120 > Project: HBase > Issue Type: Bug >Affects Versions: 1.1.2 >Reporter: Yu Li >Assignee: Yu Li >Priority: Minor > Attachments: HBASE-15120.branch-1.1.patch > > > When checking branch-1.1 UT in HBASE-13590, found > TestSplitTransactionOnCluster#testFailedSplit will fail at a 12/50 chance. > The issue is fixed by HBASE-14883 but the change didn't go into branch-1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14877) maven archetype: client application
[
https://issues.apache.org/jira/browse/HBASE-14877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101746#comment-15101746
]
Hadoop QA commented on HBASE-14877:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
42s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 59s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 56s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 11m
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
48s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 7m 45s
{color} | {color:red} branch/. no findbugs output file
(./target/findbugsXml.xml) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 5s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 7s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
24s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 55s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 55s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 51s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 51s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 12m
36s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
3s {color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 1s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m 20s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.4.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m 39s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.4.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m 59s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.5.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m 19s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.5.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m 39s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.5.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 8m 0s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.6.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 9m 22s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.6.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 10m 43s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.6.3. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 12m 3s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 7m 48s
{color} | {color:red} patch/. no findbugs output file
(./target/findbugsXml.xml) {color} |
| {color:red}-1{color} | {color:red} findbugs {color} |
[jira] [Commented] (HBASE-14969) Add throughput controller for flush
[
https://issues.apache.org/jira/browse/HBASE-14969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101868#comment-15101868
]
Yu Li commented on HBASE-14969:
---
Checked and confirmed the UT failures and findbugs issues are not introduced by
the latest patch, and no more checkstyle issues.
> Add throughput controller for flush
> ---
>
> Key: HBASE-14969
> URL: https://issues.apache.org/jira/browse/HBASE-14969
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-14969.patch, HBASE-14969_v2.patch,
> HBASE-14969_v3.patch, HBASE-14969_v4.patch, HBASE-14969_v5.patch,
> HBASE-14969_v6.patch, load-nothrottling.log, load-throttling.log
>
>
> In HBASE-8329 we added a throughput controller for compaction, to avoid spike
> caused by huge IO pressure like network/disk overflow. However, even with
> this control on, we are still observing disk utils near 100%, and by analysis
> we think this is caused by flush, especially when we increase the setting of
> {{hbase.hstore.flusher.count}}
> In this JIRA, we propose to add throughput control feature for flush, as a
> supplement of HBASE-8329 to better control IO pressure.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15097) When the scan operation covered two regions,sometimes the final results have duplicated rows.
[
https://issues.apache.org/jira/browse/HBASE-15097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101907#comment-15101907
]
Ted Yu commented on HBASE-15097:
Is the fix correct ?
There were test failures in TestFromClientSideXX
> When the scan operation covered two regions,sometimes the final results have
> duplicated rows.
> -
>
> Key: HBASE-15097
> URL: https://issues.apache.org/jira/browse/HBASE-15097
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 1.1.2
> Environment: centos 6.5
> hbase 1.1.2
>Reporter: chenrongwei
>Assignee: chenrongwei
> Attachments: HBASE-15097-v001.patch, output.log, rowkey.txt,
> snapshot2016-01-13 pm 8.42.37.png
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> When the scan operation‘s start key and end key covered two regions,the first
> region returned the rows which were beyond of its' end key.So,this finally
> leads to duplicated rows in the results.
> To avoid this problem,we should add a judgment before setting the variable
> "stopRow" in the class of HRegion,like follow:
> if (Bytes.equals(scan.getStopRow(), HConstants.EMPTY_END_ROW) &&
> !scan.isGetScan()) {
> this.stopRow = null;
> } else {
> if (Bytes.compareTo(scan.getStopRow(),
> this.getRegionInfo().getEndKey()) >= 0) {
> this.stopRow = this.getRegionInfo().getEndKey();
> } else {
> this.stopRow = scan.getStopRow();
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15117) Resolve ICAST findbugs warnings in current codes
[
https://issues.apache.org/jira/browse/HBASE-15117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-15117:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 2.0.0
Status: Resolved (was: Patch Available)
Pushed to master branch. Thank you [~carp84] for the patch
> Resolve ICAST findbugs warnings in current codes
>
>
> Key: HBASE-15117
> URL: https://issues.apache.org/jira/browse/HBASE-15117
> Project: HBase
> Issue Type: Bug
>Reporter: Yu Li
>Assignee: Yu Li
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15117.patch
>
>
> In [findbugs
> output|https://builds.apache.org/job/PreCommit-HBASE-Build/120/artifact/patchprocess/branch-findbugs-hbase-server-warnings.html#Warnings_STYLE]
> of recent build, we could see ICAST warnings (Result of integer
> multiplication cast to long) on Compactor and ExportSnapshot
> From the code I guess the design is to avoid multiplication result to
> overflow, however current implementation cannot achieve the goal. For
> example, output of below codes
> {code}
> int i = 100;
> long a = i * i;
> long b = (long) i * i;
> System.out.println(a);
> System.out.println(b);
> {code}
> will be
> {noformat}
> -727379968
> 1
> {noformat}
> Will make some minor changes to resolve this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-15122) Servlets generate XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER
stack created HBASE-15122:
-
Summary: Servlets generate XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER
Key: HBASE-15122
URL: https://issues.apache.org/jira/browse/HBASE-15122
Project: HBase
Issue Type: Bug
Reporter: stack
Priority: Critical
In our JMXJsonServlet we are doing this:
jsonpcb = request.getParameter(CALLBACK_PARAM);
if (jsonpcb != null) {
response.setContentType("application/javascript; charset=utf8");
writer.write(jsonpcb + "(");
...
Findbugs complains rightly. There are other instances in our servlets and then
there are the pages generated by jamon excluded from findbugs checking (and
findbugs volunteers that it is dumb in this regard finding only the most
egregious of violations).
We have no sanitizing tooling in hbase that I know of (correct me if I am
wrong). I started to pull on this thread and it runs deep. Our Jamon templating
(last updated in 2013 and before that, in 2011) engine doesn't seem to have
sanitizing means either and there seems to be outstanding XSS complaint against
jamon that goes unaddressed.
Could pull in something like
https://www.owasp.org/index.php/OWASP_Java_Encoder_Project and run all
emissions via it or get a templating engine that has sanitizing built in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15120) Backport HBASE-14883 to branch-1.1
[
https://issues.apache.org/jira/browse/HBASE-15120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101827#comment-15101827
]
Hadoop QA commented on HBASE-15120:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
19s {color} | {color:green} branch-1.1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} branch-1.1 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{color} | {color:green} branch-1.1 passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
19s {color} | {color:green} branch-1.1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
19s {color} | {color:green} branch-1.1 passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 43s
{color} | {color:red} hbase-server in branch-1.1 has 79 extant Findbugs
warnings. {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 43s
{color} | {color:red} hbase-server in branch-1.1 failed with JDK v1.8.0.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} branch-1.1 passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
39s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
12m 11s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
51s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 40s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0. {color}
|
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 116m 26s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0. {color}
|
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 109m 13s
{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_79.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
29s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 254m 14s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0 Failed junit tests |
hadoop.hbase.client.TestSnapshotCloneIndependence |
| | hadoop.hbase.regionserver.wal.TestDurability |
| | hadoop.hbase.util.TestHBaseFsck |
| JDK v1.8.0 Timed out junit tests |
org.apache.hadoop.hbase.namespace.TestNamespaceAuditor |
| JDK v1.7.0_79 Failed junit tests |
hadoop.hbase.regionserver.wal.TestDurability |
| | hadoop.hbase.util.TestHBaseFsck |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12782494/HBASE-15120.branch-1.1.patch
|
| JIRA Issue | HBASE-15120 |
| Optional Tests |
[jira] [Updated] (HBASE-13590) TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey
[ https://issues.apache.org/jira/browse/HBASE-13590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-13590: -- Attachment: testEnableTableHandler_branch-1.1.log.zip Attaching the 100x test result for branch-1.1 with patch attached here, also confirmed no failure of TestEnableTableHandler. However, have observed below failed cases: ||Failed cases||Failure times|| |TestSplitTransactionOnCluster#testFailedSplit|24| |TestRateLimiter#testOverconsumptionFixedIntervalRefillStrategy|1| |TestMasterOperationsForRegionReplicas#testCreateTableWithMultipleReplicas|1| Have opened HBASE-15120 for TestSplitTransactionOnCluster#testFailedSplit. For TestRateLimiter, we have a fix for our 1.1.2 branch, and will open a JIRA to fix it later. For TestMasterOperationsForRegionReplicas, need to locate the root cause > TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey > --- > > Key: HBASE-13590 > URL: https://issues.apache.org/jira/browse/HBASE-13590 > Project: HBase > Issue Type: Test > Components: master >Reporter: Nick Dimiduk >Assignee: Yu Li > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4 > > Attachments: HBASE-13590.branch-1.1.patch, > HBASE-13590.branch-1.patch, HBASE-13590.branch-1.v2.patch, > testEnableTableHandler_branch-1.1.log.zip, > testEnableTableHandler_branch-1.log.zip > > > Looking at our [build > history|https://builds.apache.org/job/HBase-1.1/buildTimeTrend], it seems > this test is flakey. See builds 429, 431, 439. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13590) TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey
[
https://issues.apache.org/jira/browse/HBASE-13590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101846#comment-15101846
]
Yu Li commented on HBASE-13590:
---
The script I used for both branches:
{noformat}
#!/usr/bin/env bash
count=0
while ((count < 100))
do
count=$(expr $count + 1)
echo "=Round $count="
mvn -Dmaven.test.redirectTestOutputToFile=true \
-Dit.test=noItTest \
-Dhbase.skip-jacoco=false \
-Dmaven.test.failure.ignore=true \
-Dtest=TestAsyncProcess,TestMasterOperationsForRegionReplicas,TestEnableTableHandler,TestRateLimiter,TestSplitTransactionOnCluster
\
-Dsurefire.testFailureIgnore=true \
clean test
done
{noformat}
[~stack], about the truth that it failed at the first run with the branch-1.1
patch when you tried earlier today, is it possible that it was some kind of env
issue?... Please let me know your thoughts on how to move on here, thanks.
> TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey
> ---
>
> Key: HBASE-13590
> URL: https://issues.apache.org/jira/browse/HBASE-13590
> Project: HBase
> Issue Type: Test
> Components: master
>Reporter: Nick Dimiduk
>Assignee: Yu Li
> Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4
>
> Attachments: HBASE-13590.branch-1.1.patch,
> HBASE-13590.branch-1.patch, HBASE-13590.branch-1.v2.patch,
> testEnableTableHandler_branch-1.1.log.zip,
> testEnableTableHandler_branch-1.log.zip
>
>
> Looking at our [build
> history|https://builds.apache.org/job/HBase-1.1/buildTimeTrend], it seems
> this test is flakey. See builds 429, 431, 439.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15122) Servlets generate XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER findbugs warnings
[
https://issues.apache.org/jira/browse/HBASE-15122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-15122:
--
Summary: Servlets generate XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER findbugs
warnings (was: Servlets generate XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER)
> Servlets generate XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER findbugs warnings
> ---
>
> Key: HBASE-15122
> URL: https://issues.apache.org/jira/browse/HBASE-15122
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Priority: Critical
>
> In our JMXJsonServlet we are doing this:
> jsonpcb = request.getParameter(CALLBACK_PARAM);
> if (jsonpcb != null) {
> response.setContentType("application/javascript; charset=utf8");
> writer.write(jsonpcb + "(");
> ...
> Findbugs complains rightly. There are other instances in our servlets and
> then there are the pages generated by jamon excluded from findbugs checking
> (and findbugs volunteers that it is dumb in this regard finding only the most
> egregious of violations).
> We have no sanitizing tooling in hbase that I know of (correct me if I am
> wrong). I started to pull on this thread and it runs deep. Our Jamon
> templating (last updated in 2013 and before that, in 2011) engine doesn't
> seem to have sanitizing means either and there seems to be outstanding XSS
> complaint against jamon that goes unaddressed.
> Could pull in something like
> https://www.owasp.org/index.php/OWASP_Java_Encoder_Project and run all
> emissions via it or get a templating engine that has sanitizing built in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-15121) ConnectionImplementation#locateRegionInMeta() issue when master is restarted
Samir Ahmic created HBASE-15121:
---
Summary: ConnectionImplementation#locateRegionInMeta() issue when
master is restarted
Key: HBASE-15121
URL: https://issues.apache.org/jira/browse/HBASE-15121
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 2.0.0
Reporter: Samir Ahmic
Assignee: Samir Ahmic
Fix For: 2.0.0
I notice this issue while i was running IntegrationTestMTTR#testRestartMaster()
test was failing on put operation. Here is sequence of events from logs leading
to failed put operation:
Master restart
{code}
INFO [pool-5-thread-1] util.Shell: Executing full command [/usr/bin/ssh
hnode2 "sudo -u hbase ps aux | grep proc_master | grep -v grep | tr -s ' ' |
cut -d ' ' -f2 | xargs kill -s SIGKILL"]
{code}
Client trying to locate region for row=70efdf2ec9b086079795c442636b55fb-17
(this is additional logging inspecting metaKey which is used to search
hbase:meta )
{code}
2016-01-15 10:26:05,169 INFO [HBaseWriterThread_9]
client.ConnectionImplementation: metaKey inspection:
table=IntegrationTestMTTRLoadTestTool row= 70efdf2ec9b086079795c442636b55fb-17
metaKey=
IntegrationTestMTTRLoadTestTool,70efdf2ec9b086079795c442636b55fb-17,99
{code}
Client throwing TableNotFoundException (hbase:meta scan returned null)
{code}
2016-01-15 10:32:58,154 INFO [HBaseWriterThread_5]
client.ConnectionImplementation: regionInfo result is null: HBaseWriterThread_5
throwing TableNotFoundException logging details
table=IntegrationTestMTTRLoadTestTool row=70efdf2ec9b086079795c442636b55fb-17
metaKey=IntegrationTestMTTRLoadTestTool,70efdf2ec9b086079795c442636b55fb-17,99
2016-01-15 10:32:58,154 ERROR [HBaseWriterThread_5] client.AsyncProcess: Failed
to get region location
org.apache.hadoop.hbase.TableNotFoundException: IntegrationTestMTTRLoadTestTool
at
org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegionInMeta(ConnectionImplementation.java:890)
at
org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:781)
at
org.apache.hadoop.hbase.client.AsyncProcess.submit(AsyncProcess.java:396)
at
org.apache.hadoop.hbase.client.AsyncProcess.submit(AsyncProcess.java:344)
at
org.apache.hadoop.hbase.client.BufferedMutatorImpl.backgroundFlushCommits(BufferedMutatorImpl.java:239)
at
org.apache.hadoop.hbase.client.BufferedMutatorImpl.flush(BufferedMutatorImpl.java:191)
at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:949)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:569)
at
org.apache.hadoop.hbase.util.MultiThreadedWriter$HBaseWriterThread.insert(MultiThreadedWriter.java:146)
at
org.apache.hadoop.hbase.util.MultiThreadedWriter$HBaseWriterThread.run(MultiThreadedWriter.java:111)
{code}
And as result we have failed insert operation:
{code}
2016-01-15 10:32:58,179 ERROR [HBaseWriterThread_5] util.MultiThreadedWriter:
Failed to insert: 17 after 60046ms; region information: cached:
region=IntegrationTestMTTRLoadTestTool,6660,1452849956427.05b437185a9437f178726a55a29a79b7.,
hostname=hnode4,16020,1452776418437, seqNum=5; cache is up to date; errors:
exception from null for 70efdf2ec9b086079795c442636b55fb-17
org.apache.hadoop.hbase.TableNotFoundException: IntegrationTestMTTRLoadTestTool
at
org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegionInMeta(ConnectionImplementation.java:890)
at
org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:781)
at
org.apache.hadoop.hbase.client.AsyncProcess.submit(AsyncProcess.java:396)
at
org.apache.hadoop.hbase.client.AsyncProcess.submit(AsyncProcess.java:344)
at
org.apache.hadoop.hbase.client.BufferedMutatorImpl.backgroundFlushCommits(BufferedMutatorImpl.java:239)
at
org.apache.hadoop.hbase.client.BufferedMutatorImpl.flush(BufferedMutatorImpl.java:191)
at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:949)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:569)
at
org.apache.hadoop.hbase.util.MultiThreadedWriter$HBaseWriterThread.insert(MultiThreadedWriter.java:146)
at
org.apache.hadoop.hbase.util.MultiThreadedWriter$HBaseWriterThread.run(MultiThreadedWriter.java:111)
{code}
leading to test failing:
{code}
Failed to write key: 17
2016-01-15 10:33:53,984 INFO [main] mttr.IntegrationTestMTTR: RestartMaster
failed after 469878ms.
java.util.concurrent.ExecutionException: java.lang.AssertionError: Load failed
expected:<0> but was:<1>
{code}
Here is snippet from ConnectionImplementation#locateRegionInMeta() throwing
exception:
{code}
try {
Result regionInfoRow = null;
ReversedClientScanner rcs = null;
try {
rcs = new
[jira] [Commented] (HBASE-15101) Leaked References to StoreFile.Reader after HBASE-13082
[
https://issues.apache.org/jira/browse/HBASE-15101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101816#comment-15101816
]
Ted Yu commented on HBASE-15101:
{code}
379* Returns a pair of lists of scanners where the first element is the
380* selected scanners and the second element is the ignored scanners
{code}
The above no longer matches code in patch v2.
> Leaked References to StoreFile.Reader after HBASE-13082
> ---
>
> Key: HBASE-15101
> URL: https://issues.apache.org/jira/browse/HBASE-15101
> Project: HBase
> Issue Type: Bug
> Components: HFile, io
>Affects Versions: 2.0.0
>Reporter: deepankar
>Assignee: deepankar
> Attachments: HBASE-15101-v1.patch, HBASE-15101-v2.patch,
> HBASE-15101.patch
>
>
> We observed this production that after a region server dies there are huge
> number of hfiles in that region for the region server running the version
> with HBASE-13082, In the doc it is given that it is expected to happen, but
> we found a one place where scanners are not being closed. If the scanners are
> not closed their references are not decremented and that is leading to the
> issue of huge number of store files not being finalized
> All I was able to find is in the selectScannersFrom, where we discard some of
> the scanners and we are not closing them. I am attaching a patch for that.
> Also to avoid these issues should the files that are done be logged and
> finalized (moved to archive) as a part of region close operation. This will
> solve any leaks that can happen and does not cause any dire consequences?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14969) Add throughput controller for flush
[
https://issues.apache.org/jira/browse/HBASE-14969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101822#comment-15101822
]
Hadoop QA commented on HBASE-14969:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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 9 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
24s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 53s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 3s
{color} | {color:red} hbase-server in master has 83 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
41s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 2s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 4m 59s {color}
| {color:red} hbase-server-jdk1.8.0 with JDK v1.8.0 generated 6 new issues (was
6, now 6). {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 2s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 31s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 5m 30s {color}
| {color:red} hbase-server-jdk1.7.0_79 with JDK v1.7.0_79 generated 6 new
issues (was 6, now 6). {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 31s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
57s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
21m 42s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 9s
{color} | {color:red} hbase-server introduced 3 new FindBugs issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 113m 48s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0. {color}
|
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 105m 31s
{color} | {color:green} hbase-server in the patch passed with JDK v1.7.0_79.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
18s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 263m 37s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | Increment of volatile field
org.apache.hadoop.hbase.regionserver.HRegion$WriteState.compacting in
org.apache.hadoop.hbase.regionserver.HRegion.compact(CompactionContext, Store,
ThroughputController, User) At
[jira] [Updated] (HBASE-15104) Occasional failures due to NotServingRegionException in IT tests
[ https://issues.apache.org/jira/browse/HBASE-15104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-15104: --- Resolution: Fixed Status: Resolved (was: Patch Available) I'm going to close this. If it created a new checkstyle/findbugs issue we'll address on a follow up. > Occasional failures due to NotServingRegionException in IT tests > > > Key: HBASE-15104 > URL: https://issues.apache.org/jira/browse/HBASE-15104 > Project: HBase > Issue Type: Bug > Components: integration tests >Affects Versions: 1.2.0 >Reporter: huaxiang sun >Assignee: huaxiang sun > Fix For: 2.0.0, 0.94.28, 1.2.0, 1.1.3, 1.0.4 > > Attachments: HBASE-15104-v001.patch > > > IntegrationTestAcidGuarantees fails when trying to cleanup with > NotServerRegionExceptions giving up (after 36 attempts) . > 5/11/09 09:19:24 INFO client.AsyncProcess: #33, waiting for some tasks to > finish. Expected max=0, tasksInProgress=9 > 15/11/09 09:19:33 INFO client.AsyncProcess: #45, table=TestAcidGuarantees, > attempt=10/35 failed=1ops, last exception: > org.apache.hadoop.hbase.NotServingRegionException: > org.apache.hadoop.hbase.NotServingRegionException: Region > TestAcidGuarantees,test_row_1,1447089367019.032439ef4f3353cb894d20337ba043bc. > is not online on node-4.internal,22101,1447089152259 > at > org.apache.hadoop.hbase.regionserver.HRegionServer.getRegionByEncodedName(HRegionServer.java:2786) > at > org.apache.hadoop.hbase.regionserver.RSRpcServices.getRegion(RSRpcServices.java:922) > at > org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:1893) > at > org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32213) > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2035) > at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107) > at > org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130) > at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107) > at java.lang.Thread.run(Thread.java:745) > ... > Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed > after attempts=36, exceptions: > Mon Nov 09 09:19:53 PST 2015, null, java.net.SocketTimeoutException: > callTimeout=6, callDuration=68104: row 'test_row_1' > Looked at the RS log, the following exception is found: > 2015-11-10 10:07:49,091 ERROR > org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler: Failed open > of > region=TestAcidGuarantees,,1447177733243.f1be6b850fe3958c5c9b5e330b5dfb00., > starting to roll back the global memstore size. > org.apache.hadoop.hbase.DoNotRetryIOException: java.lang.RuntimeException: > java.lang.ClassNotFoundException: com.hadoop.compression.lzo.LzoCodec > at > org.apache.hadoop.hbase.util.CompressionTest.testCompression(CompressionTest.java:102) > at > org.apache.hadoop.hbase.regionserver.HRegion.checkCompressionCodecs(HRegion.java:6011) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5995) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5967) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5938) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5894) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5845) > at > org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:356) > at > org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:126) > at > org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:128) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15104) Occasional failures due to NotServingRegionException in IT tests
[ https://issues.apache.org/jira/browse/HBASE-15104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102090#comment-15102090 ] Hudson commented on HBASE-15104: FAILURE: Integrated in HBase-0.98-matrix #286 (See [https://builds.apache.org/job/HBase-0.98-matrix/286/]) HBASE-15104 Occasional failures due to NotServingRegionException in IT (jmhsieh: rev f46bee0a7dd0dd315d9681a63000ab3cfa716656) * hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/actions/ChangeCompressionAction.java > Occasional failures due to NotServingRegionException in IT tests > > > Key: HBASE-15104 > URL: https://issues.apache.org/jira/browse/HBASE-15104 > Project: HBase > Issue Type: Bug > Components: integration tests >Affects Versions: 1.2.0 >Reporter: huaxiang sun >Assignee: huaxiang sun > Fix For: 2.0.0, 0.94.28, 1.2.0, 1.1.3, 1.0.4 > > Attachments: HBASE-15104-v001.patch > > > IntegrationTestAcidGuarantees fails when trying to cleanup with > NotServerRegionExceptions giving up (after 36 attempts) . > 5/11/09 09:19:24 INFO client.AsyncProcess: #33, waiting for some tasks to > finish. Expected max=0, tasksInProgress=9 > 15/11/09 09:19:33 INFO client.AsyncProcess: #45, table=TestAcidGuarantees, > attempt=10/35 failed=1ops, last exception: > org.apache.hadoop.hbase.NotServingRegionException: > org.apache.hadoop.hbase.NotServingRegionException: Region > TestAcidGuarantees,test_row_1,1447089367019.032439ef4f3353cb894d20337ba043bc. > is not online on node-4.internal,22101,1447089152259 > at > org.apache.hadoop.hbase.regionserver.HRegionServer.getRegionByEncodedName(HRegionServer.java:2786) > at > org.apache.hadoop.hbase.regionserver.RSRpcServices.getRegion(RSRpcServices.java:922) > at > org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:1893) > at > org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32213) > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2035) > at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107) > at > org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130) > at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107) > at java.lang.Thread.run(Thread.java:745) > ... > Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed > after attempts=36, exceptions: > Mon Nov 09 09:19:53 PST 2015, null, java.net.SocketTimeoutException: > callTimeout=6, callDuration=68104: row 'test_row_1' > Looked at the RS log, the following exception is found: > 2015-11-10 10:07:49,091 ERROR > org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler: Failed open > of > region=TestAcidGuarantees,,1447177733243.f1be6b850fe3958c5c9b5e330b5dfb00., > starting to roll back the global memstore size. > org.apache.hadoop.hbase.DoNotRetryIOException: java.lang.RuntimeException: > java.lang.ClassNotFoundException: com.hadoop.compression.lzo.LzoCodec > at > org.apache.hadoop.hbase.util.CompressionTest.testCompression(CompressionTest.java:102) > at > org.apache.hadoop.hbase.regionserver.HRegion.checkCompressionCodecs(HRegion.java:6011) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5995) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5967) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5938) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5894) > at > org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:5845) > at > org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:356) > at > org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:126) > at > org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:128) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14969) Add throughput controller for flush
[
https://issues.apache.org/jira/browse/HBASE-14969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102063#comment-15102063
]
Ted Yu commented on HBASE-14969:
lgtm
> Add throughput controller for flush
> ---
>
> Key: HBASE-14969
> URL: https://issues.apache.org/jira/browse/HBASE-14969
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-14969.patch, HBASE-14969_v2.patch,
> HBASE-14969_v3.patch, HBASE-14969_v4.patch, HBASE-14969_v5.patch,
> HBASE-14969_v6.patch, load-nothrottling.log, load-throttling.log
>
>
> In HBASE-8329 we added a throughput controller for compaction, to avoid spike
> caused by huge IO pressure like network/disk overflow. However, even with
> this control on, we are still observing disk utils near 100%, and by analysis
> we think this is caused by flush, especially when we increase the setting of
> {{hbase.hstore.flusher.count}}
> In this JIRA, we propose to add throughput control feature for flush, as a
> supplement of HBASE-8329 to better control IO pressure.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15108) TestReplicationAdmin failed on branch-1.0
[ https://issues.apache.org/jira/browse/HBASE-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102103#comment-15102103 ] Hudson commented on HBASE-15108: SUCCESS: Integrated in HBase-1.0 #1135 (See [https://builds.apache.org/job/HBase-1.0/1135/]) HBASE-15108 TestReplicationAdmin failed on branch-1.0 (chenheng: rev ae8f0900fb49b222c8359256022035841b3eb53d) * hbase-server/src/test/java/org/apache/hadoop/hbase/client/replication/TestReplicationAdmin.java > TestReplicationAdmin failed on branch-1.0 > -- > > Key: HBASE-15108 > URL: https://issues.apache.org/jira/browse/HBASE-15108 > Project: HBase > Issue Type: Bug >Affects Versions: 1.0.3 >Reporter: Heng Chen >Assignee: Heng Chen > Fix For: 1.0.4 > > Attachments: HBASE-15018-branch-1.0.patch, > HBASE-15108.v1.branch-1.0.patch > > > I notice it on HBASE-15095. > See > https://builds.apache.org/job/PreCommit-HBASE-Build/95/artifact/patchprocess/patch-unit-hbase-server-jdk1.8.0.txt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-9393) Hbase does not closing a closed socket resulting in many CLOSE_WAIT
[ https://issues.apache.org/jira/browse/HBASE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102132#comment-15102132 ] Ashish Singhi commented on HBASE-9393: -- AFAIK HBase do not have any such timeout now. I have already started the implementation towards that path. Will post the patch once I thoroughly test it. Thanks for the comment. > Hbase does not closing a closed socket resulting in many CLOSE_WAIT > > > Key: HBASE-9393 > URL: https://issues.apache.org/jira/browse/HBASE-9393 > Project: HBase > Issue Type: Bug >Affects Versions: 0.94.2, 0.98.0 > Environment: Centos 6.4 - 7 regionservers/datanodes, 8 TB per node, > 7279 regions >Reporter: Avi Zrachya > > HBase dose not close a dead connection with the datanode. > This resulting in over 60K CLOSE_WAIT and at some point HBase can not connect > to the datanode because too many mapped sockets from one host to another on > the same port. > The example below is with low CLOSE_WAIT count because we had to restart > hbase to solve the porblem, later in time it will incease to 60-100K sockets > on CLOSE_WAIT > [root@hd2-region3 ~]# netstat -nap |grep CLOSE_WAIT |grep 21592 |wc -l > 13156 > [root@hd2-region3 ~]# ps -ef |grep 21592 > root 17255 17219 0 12:26 pts/000:00:00 grep 21592 > hbase21592 1 17 Aug29 ?03:29:06 > /usr/java/jdk1.6.0_26/bin/java -XX:OnOutOfMemoryError=kill -9 %p -Xmx8000m > -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode > -Dhbase.log.dir=/var/log/hbase > -Dhbase.log.file=hbase-hbase-regionserver-hd2-region3.swnet.corp.log ... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14877) maven archetype: client application
[
https://issues.apache.org/jira/browse/HBASE-14877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102131#comment-15102131
]
Sean Busbey commented on HBASE-14877:
-
no worries! always happy to help new folks to HBase and downstream users of
Yetus, so this is a two-for-one. ;)
{quote}
The "findbugs" step is failing in the master branch before my patch is applied.
The message says that "no findbugs output file" is found in the root's ./target
subdirectory. As far as I can see, the lack of findbugs output is to be
expected, since there is NO java code in the root's ./src subdirectory for
findbugs to inspect.
{quote}
Yes, yetus by default reports on the health of the repository both before and
after a given patch. this is both so that folks can generally be aware of how
the code base is doing (for example, there are now hbase jiras for fixing the
extent findbugs errors in some modules) and so that patches that are fixing
findbugs errors are obvious.
The particular bug of "no java code gives a findbugs -1" is YETUS-271, which
will be fixed in the next release. If all of the modules that are failing
findbugs have no java code, then I'd say they can safely be ignored.
> maven archetype: client application
> ---
>
> Key: HBASE-14877
> URL: https://issues.apache.org/jira/browse/HBASE-14877
> Project: HBase
> Issue Type: Sub-task
> Components: build, Usability
>Affects Versions: 2.0.0
>Reporter: Nick Dimiduk
>Assignee: Daniel Vimont
> Labels: archetype, beginner, maven
> Attachments: HBASE-14877-v2.patch, HBASE-14877-v3.patch,
> HBASE-14877.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15100) Master WALProcs still never clean up
[
https://issues.apache.org/jira/browse/HBASE-15100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102192#comment-15102192
]
Matteo Bertozzi commented on HBASE-15100:
-
still looking to see if I found other stuff, but I think the main problem was a
wal deleted too early. (see TestWALProcedureStore#testNoTrailerDoubleRestart).
The patch also resolves one of the pending TODOs where on replay of completed
procedures we avoid the conversion to the Procedure instance going directly to
the ProcedureInfo (used to track the result). This should also provide some
speedup on replay and allow downgrades (when a clean restart/shutdown is done).
there is another TODO about rewriting long waiting procs to the new WAL which
will be the one that will avoid a large amount of WALs kept around even in case
of bugs, but maybe I'll open another jira for that. since at the moment we
don't have procs with a long life span.
> Master WALProcs still never clean up
>
>
> Key: HBASE-15100
> URL: https://issues.apache.org/jira/browse/HBASE-15100
> Project: HBase
> Issue Type: Bug
> Components: master, proc-v2
>Affects Versions: 1.2.0
>Reporter: Elliott Clark
>Assignee: Matteo Bertozzi
>Priority: Critical
> Attachments: HBASE-15100-v0.patch
>
>
> {code}
> bin/hdfs dfs -ls /hbase/MasterProcWALs | wc -l
> 218631
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15097) When the scan operation covered two regions,sometimes the final results have duplicated rows.
[
https://issues.apache.org/jira/browse/HBASE-15097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102039#comment-15102039
]
chenrongwei commented on HBASE-15097:
-
Sorry,I didn't consider the situation of the reverse scan,i will fix that
problem and make sure it's ok.
> When the scan operation covered two regions,sometimes the final results have
> duplicated rows.
> -
>
> Key: HBASE-15097
> URL: https://issues.apache.org/jira/browse/HBASE-15097
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 1.1.2
> Environment: centos 6.5
> hbase 1.1.2
>Reporter: chenrongwei
>Assignee: chenrongwei
> Attachments: HBASE-15097-v001.patch, output.log, rowkey.txt,
> snapshot2016-01-13 pm 8.42.37.png
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> When the scan operation‘s start key and end key covered two regions,the first
> region returned the rows which were beyond of its' end key.So,this finally
> leads to duplicated rows in the results.
> To avoid this problem,we should add a judgment before setting the variable
> "stopRow" in the class of HRegion,like follow:
> if (Bytes.equals(scan.getStopRow(), HConstants.EMPTY_END_ROW) &&
> !scan.isGetScan()) {
> this.stopRow = null;
> } else {
> if (Bytes.compareTo(scan.getStopRow(),
> this.getRegionInfo().getEndKey()) >= 0) {
> this.stopRow = this.getRegionInfo().getEndKey();
> } else {
> this.stopRow = scan.getStopRow();
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15118) Fix findbugs complaint in hbase-server
[ https://issues.apache.org/jira/browse/HBASE-15118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15118: -- Attachment: 15118v2.patch Here is fixup for the rest of the server complaint > Fix findbugs complaint in hbase-server > -- > > Key: HBASE-15118 > URL: https://issues.apache.org/jira/browse/HBASE-15118 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: stack > Attachments: 15118.patch, 15118v2.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15115) Fix findbugs complaints in hbase-client
[ https://issues.apache.org/jira/browse/HBASE-15115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15115: -- Attachment: none_fix.txt Run a null patch to see where we are at with findbugs reports. Common and client should be done. > Fix findbugs complaints in hbase-client > --- > > Key: HBASE-15115 > URL: https://issues.apache.org/jira/browse/HBASE-15115 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: stack >Assignee: stack > Attachments: 15115.patch, none_fix.txt > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15117) Resolve ICAST findbugs warnings in current codes
[
https://issues.apache.org/jira/browse/HBASE-15117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102346#comment-15102346
]
Hudson commented on HBASE-15117:
FAILURE: Integrated in HBase-Trunk_matrix #635 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/635/])
HBASE-15117 Resolve ICAST findbugs warnings in current codes (Yu Li) (stack:
rev cb17c7a97a1e2eb0ebd532f614191e4edbb9e49b)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/Compactor.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/ExportSnapshot.java
> Resolve ICAST findbugs warnings in current codes
>
>
> Key: HBASE-15117
> URL: https://issues.apache.org/jira/browse/HBASE-15117
> Project: HBase
> Issue Type: Bug
>Reporter: Yu Li
>Assignee: Yu Li
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15117.patch
>
>
> In [findbugs
> output|https://builds.apache.org/job/PreCommit-HBASE-Build/120/artifact/patchprocess/branch-findbugs-hbase-server-warnings.html#Warnings_STYLE]
> of recent build, we could see ICAST warnings (Result of integer
> multiplication cast to long) on Compactor and ExportSnapshot
> From the code I guess the design is to avoid multiplication result to
> overflow, however current implementation cannot achieve the goal. For
> example, output of below codes
> {code}
> int i = 100;
> long a = i * i;
> long b = (long) i * i;
> System.out.println(a);
> System.out.println(b);
> {code}
> will be
> {noformat}
> -727379968
> 1
> {noformat}
> Will make some minor changes to resolve this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14876) Provide maven archetypes
[ https://issues.apache.org/jira/browse/HBASE-14876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102206#comment-15102206 ] Sean Busbey commented on HBASE-14876: - that sounds perfect. is the patch for that going into this issue or one of the child issues? > Provide maven archetypes > > > Key: HBASE-14876 > URL: https://issues.apache.org/jira/browse/HBASE-14876 > Project: HBase > Issue Type: New Feature > Components: build, Usability >Affects Versions: 2.0.0 >Reporter: Nick Dimiduk >Assignee: Daniel Vimont > Labels: beginner, maven > Attachments: HBASE-14876-v2.patch, HBASE-14876.patch, > archetype_prototype.zip, archetype_prototype02.zip, > archetype_shaded_prototype01.zip > > > To help onboard new users, we should provide maven archetypes for hbase > client applications. Off the top of my head, we should have templates for > - hbase client application with all dependencies > - hbase client application using client-shaded jar > - mapreduce application with hbase as input and output (ie, copy table) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15100) Master WALProcs still never clean up
[
https://issues.apache.org/jira/browse/HBASE-15100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-15100:
Attachment: TestWalProcedure.java
The long running TestWalProcedure attached simulate a lot of procedure running,
and lots of logs created but they seems to always cleanup quickly. keeping
around few logs
> Master WALProcs still never clean up
>
>
> Key: HBASE-15100
> URL: https://issues.apache.org/jira/browse/HBASE-15100
> Project: HBase
> Issue Type: Bug
> Components: master, proc-v2
>Affects Versions: 1.2.0
>Reporter: Elliott Clark
>Assignee: Matteo Bertozzi
>Priority: Critical
> Attachments: HBASE-15100-v0.patch, TestWalProcedure.java
>
>
> {code}
> bin/hdfs dfs -ls /hbase/MasterProcWALs | wc -l
> 218631
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14375) define public API for spark integration module
[ https://issues.apache.org/jira/browse/HBASE-14375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102232#comment-15102232 ] Sean Busbey commented on HBASE-14375: - not to my knowledge. [~ted.m], any insight here? the goal would be to mark the minimum class footprint that gets downstream folks the functionality we're promising. > define public API for spark integration module > -- > > Key: HBASE-14375 > URL: https://issues.apache.org/jira/browse/HBASE-14375 > Project: HBase > Issue Type: Task > Components: spark >Reporter: Sean Busbey >Priority: Critical > > before we can put the spark integration module into a release, we need to > annotate its public api surface. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14376) move hbase spark integration examples into their own module
[ https://issues.apache.org/jira/browse/HBASE-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102234#comment-15102234 ] Sean Busbey commented on HBASE-14376: - cc/[~apurtell] > move hbase spark integration examples into their own module > --- > > Key: HBASE-14376 > URL: https://issues.apache.org/jira/browse/HBASE-14376 > Project: HBase > Issue Type: Task > Components: pom, spark >Reporter: Sean Busbey >Assignee: Gabor Liptak > Labels: beginner > Attachments: HBASE-14376.1.patch, warnings.diff > > > take the examples that are currently in the hbase-spark module and move them > into a hbase-spark-examples module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15115) Fix findbugs complaints in hbase-client
[ https://issues.apache.org/jira/browse/HBASE-15115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102239#comment-15102239 ] stack commented on HBASE-15115: --- Thanks Nick. Let me commit. Will do follow on if I've missed any (the complaint above seems to be pre-patch and all in it are addressed by the patch). > Fix findbugs complaints in hbase-client > --- > > Key: HBASE-15115 > URL: https://issues.apache.org/jira/browse/HBASE-15115 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: stack >Assignee: stack > Attachments: 15115.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15075) Allow region split request to carry identification information
[ https://issues.apache.org/jira/browse/HBASE-15075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102380#comment-15102380 ] Jerry He commented on HBASE-15075: -- I looked through the latest patch. Overall looks good to me. > Allow region split request to carry identification information > -- > > Key: HBASE-15075 > URL: https://issues.apache.org/jira/browse/HBASE-15075 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Attachments: 15075-v0.txt, 15075-v1.txt, 15075-v2.txt, > HBASE-15075.v2.patch, HBASE-15075.v3.patch, HBASE-15075.v4.patch, > HBASE-15075.v5.patch > > > During the process of improving region normalization feature, I found that if > region split request triggered by the execution of SplitNormalizationPlan > fails, there is no way of knowing whether the failed split originated from > region normalization. > The association of particular split request with outcome of split would give > RegionNormalizer information so that it can make better normalization > decisions in the subsequent invocations. > One approach is to embed metadata, such as a UUID, in SplitRequest which gets > passed through RegionStateTransitionContext when > RegionServerServices#reportRegionStateTransition() is called. > This way, RegionStateListener can be notified with the metadata (id of the > requester). > See discussion on dev mailing list > http://search-hadoop.com/m/YGbbCXdkivihp2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-9393) Hbase does not closing a closed socket resulting in many CLOSE_WAIT
[ https://issues.apache.org/jira/browse/HBASE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102383#comment-15102383 ] Colin Patrick McCabe commented on HBASE-9393: - The timeout that I'm talking about is inside DFSClient.java, not inside HBase. HDFS-4911 fixed a problem where the timeout was too long. Can you be a little bit clearer on what you'd like to implement, and what you see as the problem here? > Hbase does not closing a closed socket resulting in many CLOSE_WAIT > > > Key: HBASE-9393 > URL: https://issues.apache.org/jira/browse/HBASE-9393 > Project: HBase > Issue Type: Bug >Affects Versions: 0.94.2, 0.98.0 > Environment: Centos 6.4 - 7 regionservers/datanodes, 8 TB per node, > 7279 regions >Reporter: Avi Zrachya > > HBase dose not close a dead connection with the datanode. > This resulting in over 60K CLOSE_WAIT and at some point HBase can not connect > to the datanode because too many mapped sockets from one host to another on > the same port. > The example below is with low CLOSE_WAIT count because we had to restart > hbase to solve the porblem, later in time it will incease to 60-100K sockets > on CLOSE_WAIT > [root@hd2-region3 ~]# netstat -nap |grep CLOSE_WAIT |grep 21592 |wc -l > 13156 > [root@hd2-region3 ~]# ps -ef |grep 21592 > root 17255 17219 0 12:26 pts/000:00:00 grep 21592 > hbase21592 1 17 Aug29 ?03:29:06 > /usr/java/jdk1.6.0_26/bin/java -XX:OnOutOfMemoryError=kill -9 %p -Xmx8000m > -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode > -Dhbase.log.dir=/var/log/hbase > -Dhbase.log.file=hbase-hbase-regionserver-hd2-region3.swnet.corp.log ... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14962) TestSplitWalDataLoss fails on all branches
[
https://issues.apache.org/jira/browse/HBASE-14962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102463#comment-15102463
]
stack commented on HBASE-14962:
---
In the two logs that @eclark posted and in a fail I reproduced here locally,
root issue is that when we go to to put to table in the test, we get
org.apache.hadoop.hbase.TableNotFoundException: TestSplitWalDataLoss:dataloss.
So far, seems like test setup issue rather than a dataloss. Will be back.
> TestSplitWalDataLoss fails on all branches
> --
>
> Key: HBASE-14962
> URL: https://issues.apache.org/jira/browse/HBASE-14962
> Project: HBase
> Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: stack
>Priority: Blocker
> Fix For: 1.2.0
>
> Attachments:
> org.apache.hadoop.hbase.regionserver.TestSplitWalDataLoss-output.txt,
> org.apache.hadoop.hbase.regionserver.TestSplitWalDataLoss-output.txt
>
>
> With some regularity I am seeing:
> {code}
> org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1
> action: TestSplitWalDataLoss:dataloss: 1 time,
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:228)
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$1800(AsyncProcess.java:208)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForAllPreviousOpsAndReset(AsyncProcess.java:1712)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.backgroundFlushCommits(BufferedMutatorImpl.java:240)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.flush(BufferedMutatorImpl.java:190)
> at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1430)
> at org.apache.hadoop.hbase.client.HTable.put(HTable.java:1021)
> at
> org.apache.hadoop.hbase.regionserver.TestSplitWalDataLoss.test(TestSplitWalDataLoss.java:121)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15075) Allow region split request to carry identification information
[ https://issues.apache.org/jira/browse/HBASE-15075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15075: --- Hadoop Flags: Reviewed Fix Version/s: 1.3.0 2.0.0 Thanks for the review, Jerry. Will wait for a day before committing - if there is no further review comment. > Allow region split request to carry identification information > -- > > Key: HBASE-15075 > URL: https://issues.apache.org/jira/browse/HBASE-15075 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.3.0 > > Attachments: 15075-v0.txt, 15075-v1.txt, 15075-v2.txt, > HBASE-15075.v2.patch, HBASE-15075.v3.patch, HBASE-15075.v4.patch, > HBASE-15075.v5.patch > > > During the process of improving region normalization feature, I found that if > region split request triggered by the execution of SplitNormalizationPlan > fails, there is no way of knowing whether the failed split originated from > region normalization. > The association of particular split request with outcome of split would give > RegionNormalizer information so that it can make better normalization > decisions in the subsequent invocations. > One approach is to embed metadata, such as a UUID, in SplitRequest which gets > passed through RegionStateTransitionContext when > RegionServerServices#reportRegionStateTransition() is called. > This way, RegionStateListener can be notified with the metadata (id of the > requester). > See discussion on dev mailing list > http://search-hadoop.com/m/YGbbCXdkivihp2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15106) Procedure V2 - Procedure Queue pass Procedure for better debuggability
[ https://issues.apache.org/jira/browse/HBASE-15106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102526#comment-15102526 ] Stephen Yuan Jiang commented on HBASE-15106: +1 LGTM > Procedure V2 - Procedure Queue pass Procedure for better debuggability > -- > > Key: HBASE-15106 > URL: https://issues.apache.org/jira/browse/HBASE-15106 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0, 1.3.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15106-v0.patch, HBASE-15106-v1.patch > > > Changes the various acquire/release methods to take the Procedure as argument. > That allows better debuggability. > (The patch it is just a refactor, it does not introduce any new thing) > https://reviews.apache.org/r/42271/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12426) Dead Region Servers after Decommissioning
[ https://issues.apache.org/jira/browse/HBASE-12426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102527#comment-15102527 ] Nishanth Shajahan commented on HBASE-12426: --- [~daisuke.kobayashi] yes i had to but I was more worried about manually deleting the WAL entries.Did that since it was a play around data. > Dead Region Servers after Decommissioning > -- > > Key: HBASE-12426 > URL: https://issues.apache.org/jira/browse/HBASE-12426 > Project: HBase > Issue Type: Bug > Components: Balancer >Affects Versions: 0.96.1.1 > Environment: RHEL 6.5 >Reporter: Nishanth Shajahan >Priority: Minor > > I initially had a set of 5 region servers which had a single table which > was pre split into 30 regions and was evenly distributed to all the regions > with data.I then went ahead and removed/decommissioned a coupe of region > servers,so in the end I have 3 region servers.Ran hbase hbck and verified > there were 0 inconsistencies.However when 'status' command is issued is from > hbase shell it shows a dead region server and the same is displayed in > master UI as well.Fail over of hbase master did not fix the issue.On > investigation we could see some WAL entries which was still pointing to the > old region server. > /hbase/WALs/myserver,60020,1406745344969-splitting > After removing these orphan entries from hdfs and master failover the dead > region servers went away.I wonder if this could have caused any replication > issues in the cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15101) Leaked References to StoreFile.Reader after HBASE-13082
[ https://issues.apache.org/jira/browse/HBASE-15101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102559#comment-15102559 ] deepankar commented on HBASE-15101: --- Ah sorry, fixed it > Leaked References to StoreFile.Reader after HBASE-13082 > --- > > Key: HBASE-15101 > URL: https://issues.apache.org/jira/browse/HBASE-15101 > Project: HBase > Issue Type: Bug > Components: HFile, io >Affects Versions: 2.0.0 >Reporter: deepankar >Assignee: deepankar > Attachments: HBASE-15101-v1.patch, HBASE-15101-v2.patch, > HBASE-15101-v3.patch, HBASE-15101.patch > > > We observed this production that after a region server dies there are huge > number of hfiles in that region for the region server running the version > with HBASE-13082, In the doc it is given that it is expected to happen, but > we found a one place where scanners are not being closed. If the scanners are > not closed their references are not decremented and that is leading to the > issue of huge number of store files not being finalized > All I was able to find is in the selectScannersFrom, where we discard some of > the scanners and we are not closing them. I am attaching a patch for that. > Also to avoid these issues should the files that are done be logged and > finalized (moved to archive) as a part of region close operation. This will > solve any leaks that can happen and does not cause any dire consequences? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15101) Leaked References to StoreFile.Reader after HBASE-13082
[ https://issues.apache.org/jira/browse/HBASE-15101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] deepankar updated HBASE-15101: -- Attachment: HBASE-15101-v3.patch > Leaked References to StoreFile.Reader after HBASE-13082 > --- > > Key: HBASE-15101 > URL: https://issues.apache.org/jira/browse/HBASE-15101 > Project: HBase > Issue Type: Bug > Components: HFile, io >Affects Versions: 2.0.0 >Reporter: deepankar >Assignee: deepankar > Attachments: HBASE-15101-v1.patch, HBASE-15101-v2.patch, > HBASE-15101-v3.patch, HBASE-15101.patch > > > We observed this production that after a region server dies there are huge > number of hfiles in that region for the region server running the version > with HBASE-13082, In the doc it is given that it is expected to happen, but > we found a one place where scanners are not being closed. If the scanners are > not closed their references are not decremented and that is leading to the > issue of huge number of store files not being finalized > All I was able to find is in the selectScannersFrom, where we discard some of > the scanners and we are not closing them. I am attaching a patch for that. > Also to avoid these issues should the files that are done be logged and > finalized (moved to archive) as a part of region close operation. This will > solve any leaks that can happen and does not cause any dire consequences? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15101) Leaked References to StoreFile.Reader after HBASE-13082
[
https://issues.apache.org/jira/browse/HBASE-15101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102569#comment-15102569
]
deepankar commented on HBASE-15101:
---
In StoreScanner, can the close(false) not being called lead to these references
getting leaked ? I am seeing a couple of places where the {code} return
scannerContext.setScannerState(NextState.NO_MORE_VALUES).hasMoreValues();
{code} not being preceded with close and some places that statement is preceded
with close.
Also the shipped() method in storeFileScanner does not contain the decrement,
is it because in the case of Scan.next() we want to keep scanning the same
files ??
> Leaked References to StoreFile.Reader after HBASE-13082
> ---
>
> Key: HBASE-15101
> URL: https://issues.apache.org/jira/browse/HBASE-15101
> Project: HBase
> Issue Type: Bug
> Components: HFile, io
>Affects Versions: 2.0.0
>Reporter: deepankar
>Assignee: deepankar
> Attachments: HBASE-15101-v1.patch, HBASE-15101-v2.patch,
> HBASE-15101-v3.patch, HBASE-15101.patch
>
>
> We observed this production that after a region server dies there are huge
> number of hfiles in that region for the region server running the version
> with HBASE-13082, In the doc it is given that it is expected to happen, but
> we found a one place where scanners are not being closed. If the scanners are
> not closed their references are not decremented and that is leading to the
> issue of huge number of store files not being finalized
> All I was able to find is in the selectScannersFrom, where we discard some of
> the scanners and we are not closing them. I am attaching a patch for that.
> Also to avoid these issues should the files that are done be logged and
> finalized (moved to archive) as a part of region close operation. This will
> solve any leaks that can happen and does not cause any dire consequences?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15115) Fix findbugs complaints in hbase-client
[
https://issues.apache.org/jira/browse/HBASE-15115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102586#comment-15102586
]
Hadoop QA commented on HBASE-15115:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m 1s
{color} | {color:blue} The patch file was not named according to hbase's naming
conventions. Please see
https://yetus.apache.org/documentation/latest/precommit-patchnames for
instructions. {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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
40s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 0s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 57s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 32s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 10s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 23s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 23s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 59s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 59s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
48s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 1s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m 22s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.4.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m 41s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.4.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 4m 1s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.5.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m 20s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.5.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m 40s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.5.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 8m 0s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.6.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 9m 21s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.6.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 10m 40s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.6.3. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 12m 0s
{color} | {color:red} Patch causes 11 errors with Hadoop v2.7.1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 3s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 9s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 104m 33s
{color} | {color:green} root in the patch passed with JDK v1.8.0. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 97m 25s
{color} | {color:green} root in the patch
[jira] [Commented] (HBASE-15065) SimpleRegionNormalizer should return multiple normalization plans in one run
[ https://issues.apache.org/jira/browse/HBASE-15065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102602#comment-15102602 ] Mikhail Antonov commented on HBASE-15065: - [~te...@apache.org] do you want to prevent situation when too many splits are triggered at the same time? > SimpleRegionNormalizer should return multiple normalization plans in one run > > > Key: HBASE-15065 > URL: https://issues.apache.org/jira/browse/HBASE-15065 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: 15065-v1.txt, 15065-v2.txt, 15065.addendum > > > This is follow up to HBASE-14867 w.r.t. SimpleRegionNormalizer > Outline for enhancements: > * adjustment to the period when SimpleRegionNormalizer runs > * explore merge opportunities among all neighboring region pairs > * return multiple normalization plans -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15075) Allow region split request to carry identification information
[ https://issues.apache.org/jira/browse/HBASE-15075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102795#comment-15102795 ] Ted Yu commented on HBASE-15075: bq. I'd say if we need to have structure to keep track of failed plans, we may not need to have recent plans? Addressed in patch v7. bq. setRegionStateListener should be renamed to add* now? Addressed in patch v7. Master now registers two listeners: quota manager and one for region split plan. > Allow region split request to carry identification information > -- > > Key: HBASE-15075 > URL: https://issues.apache.org/jira/browse/HBASE-15075 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.3.0 > > Attachments: 15075-v0.txt, 15075-v1.txt, 15075-v2.txt, > HBASE-15075.v2.patch, HBASE-15075.v3.patch, HBASE-15075.v4.patch, > HBASE-15075.v5.patch, HBASE-15075.v6.patch, HBASE-15075.v7.patch > > > During the process of improving region normalization feature, I found that if > region split request triggered by the execution of SplitNormalizationPlan > fails, there is no way of knowing whether the failed split originated from > region normalization. > The association of particular split request with outcome of split would give > RegionNormalizer information so that it can make better normalization > decisions in the subsequent invocations. > One approach is to embed metadata, such as a UUID, in SplitRequest which gets > passed through RegionStateTransitionContext when > RegionServerServices#reportRegionStateTransition() is called. > This way, RegionStateListener can be notified with the metadata (id of the > requester). > See discussion on dev mailing list > http://search-hadoop.com/m/YGbbCXdkivihp2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15059) Allow 0.94 to compile against Hadoop 2.7.x
[ https://issues.apache.org/jira/browse/HBASE-15059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102872#comment-15102872 ] Lars Hofhansl commented on HBASE-15059: --- [~busbey], aren't the new instructions just to build with JDK7 or later? > Allow 0.94 to compile against Hadoop 2.7.x > -- > > Key: HBASE-15059 > URL: https://issues.apache.org/jira/browse/HBASE-15059 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 0.94.28 > > Attachments: 15059-v2.txt, 15059.txt > > > Currently HBase 0.94 cannot be compiled against Hadoop 2.7. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14771) RpcServer#getRemoteAddress always returns null
[
https://issues.apache.org/jira/browse/HBASE-14771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-14771:
---
Attachment: HBASE-14771-addendum-0.98.patch
Addendum adds a null check for 'call.connection' as well. Patch based on 0.98
but the change is the same everywhere.
> RpcServer#getRemoteAddress always returns null
> --
>
> Key: HBASE-14771
> URL: https://issues.apache.org/jira/browse/HBASE-14771
> Project: HBase
> Issue Type: Bug
> Components: IPC/RPC
>Affects Versions: 1.2.0
>Reporter: Abhishek Kumar
>Assignee: Abhishek Kumar
>Priority: Minor
> Fix For: 2.0.0, 1.2.0, 1.3.0, 0.98.17
>
> Attachments: 14771-V2.patch, HBASE-14771-V1.patch,
> HBASE-14771-V2.patch, HBASE-14771-addendum-0.98.patch, HBASE-14771.patch
>
>
> RpcServer.getRemoteAddress always returns null, because Call object is
> getting initialized with null.This seems to be happening because of using
> RpcServer.getRemoteIp() in Call object constructor before RpcServer thread
> local 'CurCall' being set in CallRunner.run method:
> {noformat}
> // --- RpcServer.java ---
> protected void processRequest(byte[] buf) throws IOException,
> InterruptedException {
> .
> // Call object getting initialized here with address
> // obtained from RpcServer.getRemoteIp()
> Call call = new Call(id, this.service, md, header, param, cellScanner, this,
> responder,
> totalRequestSize, traceInfo, RpcServer.getRemoteIp());
> scheduler.dispatch(new CallRunner(RpcServer.this, call));
> }
> // getRemoteIp method gets address from threadlocal 'CurCall' which
> // gets set in CallRunner.run and calling it before this as in above case,
> will return null
> // --- CallRunner.java ---
> public void run() {
> .
> Pair resultPair = null;
> RpcServer.CurCall.set(call);
> ..
> }
> // Using 'this.addr' in place of getRemoteIp method in RpcServer.java seems
> to be fixing this issue
> Call call = new Call(id, this.service, md, header, param, cellScanner, this,
> responder,
> totalRequestSize, traceInfo, this.addr);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15101) Leaked References to StoreFile.Reader after HBASE-13082
[
https://issues.apache.org/jira/browse/HBASE-15101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102926#comment-15102926
]
Hadoop QA commented on HBASE-15101:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
34s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 46s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
42s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 6s
{color} | {color:red} hbase-server in master has 81 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 30s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
50s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
52s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
23m 8s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 30s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 95m 53s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 89m 29s
{color} | {color:green} hbase-server in the patch passed with JDK v1.7.0_79.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
13s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 231m 55s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0 Failed junit tests |
hadoop.hbase.security.token.TestZKSecretWatcher |
| JDK v1.8.0 Timed out junit tests |
org.apache.hadoop.hbase.client.replication.TestReplicationAdminWithClusters |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12782620/HBASE-15101-v3.patch |
| JIRA Issue | HBASE-15101 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf903.gq1.ygridcore.net
[jira] [Commented] (HBASE-15114) NPE when IPC server ByteBuffer reservoir is turned off
[
https://issues.apache.org/jira/browse/HBASE-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102945#comment-15102945
]
Hudson commented on HBASE-15114:
SUCCESS: Integrated in HBase-1.3-IT #439 (See
[https://builds.apache.org/job/HBase-1.3-IT/439/])
HBASE-15114 NPE when IPC server ByteBuffer reservoir is turned off (enis: rev
795f91439c8b704b6929dcdcb433bea44beea9ac)
* hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcServer.java
> NPE when IPC server ByteBuffer reservoir is turned off
> ---
>
> Key: HBASE-15114
> URL: https://issues.apache.org/jira/browse/HBASE-15114
> Project: HBase
> Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: hbase-15114.patch
>
>
> I was testing something else, and discovered that if we turn off the ipc
> out-buffer reservoir, we are getting NPEs after HBASE-14942.
> {code}
> 2016-01-14 15:29:35,865 WARN
> [PriorityRpcServer.handler=10,queue=0,port=16020] ipc.RpcServer:
> PriorityRpcServer.handler=10,queue=0,port=16020: caught:
> java.lang.NullPointerException
> at org.apache.hadoop.hbase.ipc.RpcServer$Call.done(RpcServer.java:358)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.processResponse(RpcServer.java:1159)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.doRespond(RpcServer.java:1209)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Call.sendResponseIfReady(RpcServer.java:574)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:135)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15114) NPE when IPC server ByteBuffer reservoir is turned off
[
https://issues.apache.org/jira/browse/HBASE-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102964#comment-15102964
]
Hudson commented on HBASE-15114:
SUCCESS: Integrated in HBase-1.2-IT #397 (See
[https://builds.apache.org/job/HBase-1.2-IT/397/])
HBASE-15114 NPE when IPC server ByteBuffer reservoir is turned off (enis: rev
c2e6a71d49caaea668984466ab244038a1cdbb2c)
* hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcServer.java
> NPE when IPC server ByteBuffer reservoir is turned off
> ---
>
> Key: HBASE-15114
> URL: https://issues.apache.org/jira/browse/HBASE-15114
> Project: HBase
> Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: hbase-15114.patch
>
>
> I was testing something else, and discovered that if we turn off the ipc
> out-buffer reservoir, we are getting NPEs after HBASE-14942.
> {code}
> 2016-01-14 15:29:35,865 WARN
> [PriorityRpcServer.handler=10,queue=0,port=16020] ipc.RpcServer:
> PriorityRpcServer.handler=10,queue=0,port=16020: caught:
> java.lang.NullPointerException
> at org.apache.hadoop.hbase.ipc.RpcServer$Call.done(RpcServer.java:358)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.processResponse(RpcServer.java:1159)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.doRespond(RpcServer.java:1209)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Call.sendResponseIfReady(RpcServer.java:574)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:135)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15075) Allow region split request to carry identification information
[ https://issues.apache.org/jira/browse/HBASE-15075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15075: --- Attachment: HBASE-15075.v8.patch Patch v8 fixes test failure in TestSplitTransactionOnCluster due to missing null check. > Allow region split request to carry identification information > -- > > Key: HBASE-15075 > URL: https://issues.apache.org/jira/browse/HBASE-15075 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.3.0 > > Attachments: 15075-v0.txt, 15075-v1.txt, 15075-v2.txt, > HBASE-15075.v2.patch, HBASE-15075.v3.patch, HBASE-15075.v4.patch, > HBASE-15075.v5.patch, HBASE-15075.v6.patch, HBASE-15075.v7.patch, > HBASE-15075.v8.patch > > > During the process of improving region normalization feature, I found that if > region split request triggered by the execution of SplitNormalizationPlan > fails, there is no way of knowing whether the failed split originated from > region normalization. > The association of particular split request with outcome of split would give > RegionNormalizer information so that it can make better normalization > decisions in the subsequent invocations. > One approach is to embed metadata, such as a UUID, in SplitRequest which gets > passed through RegionStateTransitionContext when > RegionServerServices#reportRegionStateTransition() is called. > This way, RegionStateListener can be notified with the metadata (id of the > requester). > See discussion on dev mailing list > http://search-hadoop.com/m/YGbbCXdkivihp2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15091) Forward-port to 1.2 HBASE-15031 "Fix merge of MVCC and SequenceID performance regression in branch-1.0"
[
https://issues.apache.org/jira/browse/HBASE-15091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102635#comment-15102635
]
Hadoop QA commented on HBASE-15091:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s {color}
| {color:red} HBASE-15091 does not apply to branch-1. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/latest/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12782630/15091v6.branch-1.patch
|
| JIRA Issue | HBASE-15091 |
| Powered by | Apache Yetus 0.1.0 http://yetus.apache.org |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/150/console |
This message was automatically generated.
> Forward-port to 1.2 HBASE-15031 "Fix merge of MVCC and SequenceID performance
> regression in branch-1.0"
> ---
>
> Key: HBASE-15091
> URL: https://issues.apache.org/jira/browse/HBASE-15091
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
>Reporter: stack
>Priority: Blocker
> Fix For: 1.2.0
>
> Attachments: 15091v2.branch-1.2.patch, 15091v3.branch-1.2.patch,
> 15091v4.branch-1.2.patch, 15091v5.branch-1.2.patch, 15091v6.branch-1.patch,
> HBASE-15091-branch-1.2.patch, HBASE-15091-branch-1.2_v1.patch,
> HBASE-15091.v1.branch-1.2.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15123) Remove duplicate code in LocalHBaseCluster and minor formatting
[ https://issues.apache.org/jira/browse/HBASE-15123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-15123: - Description: Remove duplicate code in following overloaded functions of LocalHBaseCluster: - waitOnMaster - waitOnRegionServer Also minor formatting changes. was: Remove duplicate code in following overloaded functions of LocalHBaseCluster: - waitOnMaster - waitOnRegionServer Also minor formatting changes. > Remove duplicate code in LocalHBaseCluster and minor formatting > --- > > Key: HBASE-15123 > URL: https://issues.apache.org/jira/browse/HBASE-15123 > Project: HBase > Issue Type: Improvement >Reporter: Appy >Assignee: Appy >Priority: Minor > Attachments: HBASE-15123-master-v1.patch > > > Remove duplicate code in following overloaded functions of LocalHBaseCluster: > - waitOnMaster > - waitOnRegionServer > Also minor formatting changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15123) Remove duplicate code in LocalHBaseCluster and minor formatting
[ https://issues.apache.org/jira/browse/HBASE-15123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-15123: - Description: Remove duplicate code in following overloaded functions of LocalHBaseCluster: - waitOnMaster - waitOnRegionServer Also minor formatting changes. > Remove duplicate code in LocalHBaseCluster and minor formatting > --- > > Key: HBASE-15123 > URL: https://issues.apache.org/jira/browse/HBASE-15123 > Project: HBase > Issue Type: Improvement >Reporter: Appy >Assignee: Appy >Priority: Minor > > Remove duplicate code in following overloaded functions of LocalHBaseCluster: > - waitOnMaster > - waitOnRegionServer > Also minor formatting changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15059) Allow 0.94 to compile against Hadoop 2.7.x
[ https://issues.apache.org/jira/browse/HBASE-15059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-15059: -- Release Note: This allows HBase to compile against Hadoop 2.7.1. TimeStampingFileContext.java had to be removed! If your code relied on this class to exist, do NOT upgrade to HBase 0.94.28. If your installation used this class to dump Hadoop metric to files, replace its usage with org.apache.hadoop.metrics.file.FileContext. In order to work correctly with Hadoop 2.x+ the Java classes generated for protobuf need to generated with protoc 2.5.0 before HBase is compiled. This can be done with the included build-proto.sh script. Also note that JDK7 or greater is required to build Hadoop 2.7 or later. Example: $ protoc --version check that the output indicates 2.5.0 $ dev-support/build-proto.sh $ mvn -Dhadoop.profile=2.7 ... was: This allows HBase to compile against Hadoop 2.7.1. TimeStampingFileContext.java had to be removed! If your code relied on this class to exist, do NOT upgrade to HBase 0.94.28. In order to work correctly with Hadoop 2.x+ the Java classes generated for protobuf need to generated with protoc 2.5.0 before HBase is compiled. This can be done with the included build-proto.sh script. Example: $ protoc --version check that the output indicates 2.5.0 $ dev-support/build-proto.sh $ mvn -Dhadoop.profile=2.7 ... > Allow 0.94 to compile against Hadoop 2.7.x > -- > > Key: HBASE-15059 > URL: https://issues.apache.org/jira/browse/HBASE-15059 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 0.94.28 > > Attachments: 15059-addendum.txt, 15059-v2.txt, 15059.txt > > > Currently HBase 0.94 cannot be compiled against Hadoop 2.7. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15114) NPE when IPC server ByteBuffer reservoir is turned off
[
https://issues.apache.org/jira/browse/HBASE-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15103015#comment-15103015
]
Hudson commented on HBASE-15114:
SUCCESS: Integrated in HBase-1.2 #507 (See
[https://builds.apache.org/job/HBase-1.2/507/])
HBASE-15114 NPE when IPC server ByteBuffer reservoir is turned off (enis: rev
c2e6a71d49caaea668984466ab244038a1cdbb2c)
* hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcServer.java
> NPE when IPC server ByteBuffer reservoir is turned off
> ---
>
> Key: HBASE-15114
> URL: https://issues.apache.org/jira/browse/HBASE-15114
> Project: HBase
> Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: hbase-15114.patch
>
>
> I was testing something else, and discovered that if we turn off the ipc
> out-buffer reservoir, we are getting NPEs after HBASE-14942.
> {code}
> 2016-01-14 15:29:35,865 WARN
> [PriorityRpcServer.handler=10,queue=0,port=16020] ipc.RpcServer:
> PriorityRpcServer.handler=10,queue=0,port=16020: caught:
> java.lang.NullPointerException
> at org.apache.hadoop.hbase.ipc.RpcServer$Call.done(RpcServer.java:358)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.processResponse(RpcServer.java:1159)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.doRespond(RpcServer.java:1209)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Call.sendResponseIfReady(RpcServer.java:574)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:135)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14771) RpcServer#getRemoteAddress always returns null
[
https://issues.apache.org/jira/browse/HBASE-14771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15103014#comment-15103014
]
Hudson commented on HBASE-14771:
SUCCESS: Integrated in HBase-1.2 #507 (See
[https://builds.apache.org/job/HBase-1.2/507/])
Amend HBASE-14771 RpcServer#getRemoteAddress always returns null (apurtell: rev
063d214f91e93b0057416e6723de406b3fcbfe35)
* hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcServer.java
> RpcServer#getRemoteAddress always returns null
> --
>
> Key: HBASE-14771
> URL: https://issues.apache.org/jira/browse/HBASE-14771
> Project: HBase
> Issue Type: Bug
> Components: IPC/RPC
>Affects Versions: 1.2.0
>Reporter: Abhishek Kumar
>Assignee: Abhishek Kumar
>Priority: Minor
> Fix For: 2.0.0, 1.2.0, 1.3.0, 0.98.17
>
> Attachments: 14771-V2.patch, HBASE-14771-V1.patch,
> HBASE-14771-V2.patch, HBASE-14771-addendum-0.98.patch, HBASE-14771.patch
>
>
> RpcServer.getRemoteAddress always returns null, because Call object is
> getting initialized with null.This seems to be happening because of using
> RpcServer.getRemoteIp() in Call object constructor before RpcServer thread
> local 'CurCall' being set in CallRunner.run method:
> {noformat}
> // --- RpcServer.java ---
> protected void processRequest(byte[] buf) throws IOException,
> InterruptedException {
> .
> // Call object getting initialized here with address
> // obtained from RpcServer.getRemoteIp()
> Call call = new Call(id, this.service, md, header, param, cellScanner, this,
> responder,
> totalRequestSize, traceInfo, RpcServer.getRemoteIp());
> scheduler.dispatch(new CallRunner(RpcServer.this, call));
> }
> // getRemoteIp method gets address from threadlocal 'CurCall' which
> // gets set in CallRunner.run and calling it before this as in above case,
> will return null
> // --- CallRunner.java ---
> public void run() {
> .
> Pair resultPair = null;
> RpcServer.CurCall.set(call);
> ..
> }
> // Using 'this.addr' in place of getRemoteIp method in RpcServer.java seems
> to be fixing this issue
> Call call = new Call(id, this.service, md, header, param, cellScanner, this,
> responder,
> totalRequestSize, traceInfo, this.addr);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14512) Cache UGI groups
[ https://issues.apache.org/jira/browse/HBASE-14512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15103016#comment-15103016 ] Hudson commented on HBASE-14512: SUCCESS: Integrated in HBase-1.2 #507 (See [https://builds.apache.org/job/HBase-1.2/507/]) Amend HBASE-14512 Cache UGI groups (apurtell: rev b6dc3c5ae65d69ec97e619ef739bd0221ed1efb2) * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcServer.java > Cache UGI groups > > > Key: HBASE-14512 > URL: https://issues.apache.org/jira/browse/HBASE-14512 > Project: HBase > Issue Type: Bug > Components: Performance, security >Affects Versions: 1.2.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.2.0, 1.3.0, 0.98.17 > > Attachments: HBASE-14512-addendum-0.98.patch, HBASE-14512-v1.patch, > HBASE-14512-v2.patch, HBASE-14512-v3.patch, HBASE-14512-v4.patch, > HBASE-14512.patch > > > Right now every call gets a new User object. > We should keep the same user for the life of a connection. We should also > cache the group names. However we can't cache the groups for forever as that > would mean groups don't get refreshed every 5 mins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14259) Backport Namespace quota support to 98 branch
[ https://issues.apache.org/jira/browse/HBASE-14259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14259: --- Fix Version/s: (was: 0.98.17) 0.98.18 > Backport Namespace quota support to 98 branch > -- > > Key: HBASE-14259 > URL: https://issues.apache.org/jira/browse/HBASE-14259 > Project: HBase > Issue Type: Task >Reporter: Vandana Ayyalasomayajula >Assignee: Andrew Purtell > Fix For: 0.98.18 > > Attachments: HBASE-14259_v1_0.98.patch, HBASE-14259_v2_0.98.patch, > HBASE-14259_v3_0.98.patch > > > Namespace quota support (HBASE-8410) has been backported to branch-1 > (HBASE-13438). This jira would backport the same to 98 branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14945) Backport HBASE-13153 (Bulk loaded HFile replication) to 0.98
[ https://issues.apache.org/jira/browse/HBASE-14945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14945: --- Fix Version/s: (was: 0.98.17) 0.98.18 > Backport HBASE-13153 (Bulk loaded HFile replication) to 0.98 > > > Key: HBASE-14945 > URL: https://issues.apache.org/jira/browse/HBASE-14945 > Project: HBase > Issue Type: New Feature >Reporter: Andrew Purtell > Fix For: 0.98.18 > > > HBASE-13153 (Bulk loaded HFile replication) looks like a good candidate to > backport to 0.98. It would address an important functional gap in replication > (bulk loads don't replicate) for 0.98 users, is a new feature toggled with a > new configuration parameter that is by default off, and does not change any > interfaces not marked as Private. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14792) Latest docs fail to build when packaging 0.98
[
https://issues.apache.org/jira/browse/HBASE-14792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-14792:
---
Fix Version/s: (was: 0.98.17)
0.98.18
> Latest docs fail to build when packaging 0.98
> -
>
> Key: HBASE-14792
> URL: https://issues.apache.org/jira/browse/HBASE-14792
> Project: HBase
> Issue Type: Bug
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 0.98.18
>
> Attachments: HBASE-14792-0.98.patch
>
>
> For releasing 0.98 we typically copy back the latest docs from master and
> then build.
> When I try generating the latest docs, I get:
> {noformat}
> [INFO]
>
> [INFO] Forking Apache HBase - Assembly 0.98.16-hadoop2
> [INFO]
>
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce) @ hbase-assembly ---
> [INFO]
> [INFO] --- buildnumber-maven-plugin:1.3:create-timestamp (default) @
> hbase-assembly ---
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) <
> generate-sources @ hbase <<<
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13
> [INFO] Parent project loaded from repository: org.apache:apache:pom:12
> [INFO] Relativizing decoration links with respect to project URL:
> http://hbase.apache.org
> [INFO] Rendering site with org.apache.maven.skins:maven-fluido-skin:jar:1.4
> skin.
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [INFO] Skipped "Source Xref" report, file "xref/index.html" already exists
> for the English version.
> [INFO] Skipped "Test Source Xref" report, file "xref-test/index.html" already
> exists for the English version.
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> hbase: Error during page generation: Could not find the template
> 'META-INF/maven/site.vm: Encountered "source" at META-INF/maven/site.vm[line
> 1162, column 52]
> [ERROR] Was expecting one of:
> [ERROR] "," ...
> [ERROR] ")" ...
> [ERROR] ...
> {noformat}
> Do I need to make POM updates?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14276) NPE when setting up stub for connection to master if secure connect is refused
[
https://issues.apache.org/jira/browse/HBASE-14276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-14276:
---
Fix Version/s: (was: 0.98.17)
0.98.18
> NPE when setting up stub for connection to master if secure connect is refused
> --
>
> Key: HBASE-14276
> URL: https://issues.apache.org/jira/browse/HBASE-14276
> Project: HBase
> Issue Type: Bug
>Reporter: Andrew Purtell
>Priority: Minor
> Fix For: 0.98.18
>
>
> If an insecure client contacts a secure cluster we can get an NPE when
> setting up the stub for the master connection. We should throw an IOException
> with a clear message, and not retry if possible to distinguish this case.
> Found in 0.98 but might be relevant for later branches
> {noformat}
> Aug 20, 2015 12:04:31 AM
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper
> INFO: Process identifier=hconnection-0x3c1e23ff connecting to ZooKeeper
> ensemble=x.x.x.x:2181,x.x.x.x:2181,x.x.x.x:2181
> Aug 20, 2015 12:04:31 AM
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation
> makeStub
> INFO: getMaster attempt 1 of 35 failed; retrying after sleep of 100,
> exception=com.google.protobuf.ServiceException: java.lang.NullPointerException
> Aug 20, 2015 12:04:31 AM
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation
> makeStub
> INFO: getMaster attempt 2 of 35 failed; retrying after sleep of 200,
> exception=com.google.protobuf.ServiceException: java.io.IOException: Call to
> /x.x.x.x:6 failed on local exception: java.io.EOFException
> Aug 20, 2015 12:04:31 AM
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation
> makeStub
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14870) Backport namespace permissions to 98 branch
[ https://issues.apache.org/jira/browse/HBASE-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14870: --- Fix Version/s: (was: 0.98.17) 0.98.18 > Backport namespace permissions to 98 branch > --- > > Key: HBASE-14870 > URL: https://issues.apache.org/jira/browse/HBASE-14870 > Project: HBase > Issue Type: Task >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 0.98.18 > > > Backport namespace permissions to 0.98. The new permission checks will be > disabled by default for behavioral compatibility with previous releases, like > what we did when we introduced enforcement of the EXEC permission. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14376) move hbase spark integration examples into their own module
[ https://issues.apache.org/jira/browse/HBASE-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102713#comment-15102713 ] Andrew Purtell commented on HBASE-14376: bq. Just to clarify, do you not want them merged with hbase-examples, or, not be split at all (until dependency issues are fixed)? Let's keep all code with a dependency on Spark and Scala in one module for now at least. > move hbase spark integration examples into their own module > --- > > Key: HBASE-14376 > URL: https://issues.apache.org/jira/browse/HBASE-14376 > Project: HBase > Issue Type: Task > Components: pom, spark >Reporter: Sean Busbey >Assignee: Gabor Liptak > Labels: beginner > Attachments: HBASE-14376.1.patch, warnings.diff > > > take the examples that are currently in the hbase-spark module and move them > into a hbase-spark-examples module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14962) TestSplitWalDataLoss fails on all branches
[
https://issues.apache.org/jira/browse/HBASE-14962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-14962:
--
Attachment: 14962v2.patch
Bug in first patch. This version seems to be running fine. Will let it run a
while and then report back.
> TestSplitWalDataLoss fails on all branches
> --
>
> Key: HBASE-14962
> URL: https://issues.apache.org/jira/browse/HBASE-14962
> Project: HBase
> Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: 14962.patch, 14962v2.patch,
> org.apache.hadoop.hbase.regionserver.TestSplitWalDataLoss-output.txt,
> org.apache.hadoop.hbase.regionserver.TestSplitWalDataLoss-output.txt
>
>
> With some regularity I am seeing:
> {code}
> org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1
> action: TestSplitWalDataLoss:dataloss: 1 time,
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:228)
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$1800(AsyncProcess.java:208)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForAllPreviousOpsAndReset(AsyncProcess.java:1712)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.backgroundFlushCommits(BufferedMutatorImpl.java:240)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.flush(BufferedMutatorImpl.java:190)
> at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1430)
> at org.apache.hadoop.hbase.client.HTable.put(HTable.java:1021)
> at
> org.apache.hadoop.hbase.regionserver.TestSplitWalDataLoss.test(TestSplitWalDataLoss.java:121)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15123) Remove duplicate code in LocalHBaseCluster and minor formatting
[ https://issues.apache.org/jira/browse/HBASE-15123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-15123: - Description: Remove duplicate code in following overloaded functions of LocalHBaseCluster: - waitOnMaster - waitOnRegionServer Also minor formatting changes and refactoring in MiniHBaseCluster.java. was: Remove duplicate code in following overloaded functions of LocalHBaseCluster: - waitOnMaster - waitOnRegionServer Also minor formatting changes. > Remove duplicate code in LocalHBaseCluster and minor formatting > --- > > Key: HBASE-15123 > URL: https://issues.apache.org/jira/browse/HBASE-15123 > Project: HBase > Issue Type: Improvement >Reporter: Appy >Assignee: Appy >Priority: Minor > Attachments: HBASE-15123-master-v1.patch > > > Remove duplicate code in following overloaded functions of LocalHBaseCluster: > - waitOnMaster > - waitOnRegionServer > Also minor formatting changes and refactoring in MiniHBaseCluster.java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15059) Allow 0.94 to compile against Hadoop 2.7.x
[ https://issues.apache.org/jira/browse/HBASE-15059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102882#comment-15102882 ] Lars Hofhansl commented on HBASE-15059: --- Chatted with [~stack] about TimeStampingFileContext occurring in hadoop-metrics.properties. We think it's still OK to remove. So I'll update the release notes and the instructions in the pom to use JDK7 when building with Hadoop 2.7. > Allow 0.94 to compile against Hadoop 2.7.x > -- > > Key: HBASE-15059 > URL: https://issues.apache.org/jira/browse/HBASE-15059 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 0.94.28 > > Attachments: 15059-v2.txt, 15059.txt > > > Currently HBase 0.94 cannot be compiled against Hadoop 2.7. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14376) move hbase spark integration examples into their own module
[ https://issues.apache.org/jira/browse/HBASE-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14376: --- Resolution: Won't Fix Assignee: (was: Gabor Liptak) Release Note: \ (was: HBASE-14376 Separate Spark examples) Status: Resolved (was: Patch Available) Ok, resolved as wontfix. Reopen if you disagree. > move hbase spark integration examples into their own module > --- > > Key: HBASE-14376 > URL: https://issues.apache.org/jira/browse/HBASE-14376 > Project: HBase > Issue Type: Task > Components: pom, spark >Reporter: Sean Busbey > Labels: beginner > Attachments: HBASE-14376.1.patch, warnings.diff > > > take the examples that are currently in the hbase-spark module and move them > into a hbase-spark-examples module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-14771) RpcServer#getRemoteAddress always returns null
[
https://issues.apache.org/jira/browse/HBASE-14771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-14771.
Resolution: Fixed
Committed the addendum to 0.98, branch-1.2, branch-1, and master
> RpcServer#getRemoteAddress always returns null
> --
>
> Key: HBASE-14771
> URL: https://issues.apache.org/jira/browse/HBASE-14771
> Project: HBase
> Issue Type: Bug
> Components: IPC/RPC
>Affects Versions: 1.2.0
>Reporter: Abhishek Kumar
>Assignee: Abhishek Kumar
>Priority: Minor
> Fix For: 2.0.0, 1.2.0, 1.3.0, 0.98.17
>
> Attachments: 14771-V2.patch, HBASE-14771-V1.patch,
> HBASE-14771-V2.patch, HBASE-14771-addendum-0.98.patch, HBASE-14771.patch
>
>
> RpcServer.getRemoteAddress always returns null, because Call object is
> getting initialized with null.This seems to be happening because of using
> RpcServer.getRemoteIp() in Call object constructor before RpcServer thread
> local 'CurCall' being set in CallRunner.run method:
> {noformat}
> // --- RpcServer.java ---
> protected void processRequest(byte[] buf) throws IOException,
> InterruptedException {
> .
> // Call object getting initialized here with address
> // obtained from RpcServer.getRemoteIp()
> Call call = new Call(id, this.service, md, header, param, cellScanner, this,
> responder,
> totalRequestSize, traceInfo, RpcServer.getRemoteIp());
> scheduler.dispatch(new CallRunner(RpcServer.this, call));
> }
> // getRemoteIp method gets address from threadlocal 'CurCall' which
> // gets set in CallRunner.run and calling it before this as in above case,
> will return null
> // --- CallRunner.java ---
> public void run() {
> .
> Pair resultPair = null;
> RpcServer.CurCall.set(call);
> ..
> }
> // Using 'this.addr' in place of getRemoteIp method in RpcServer.java seems
> to be fixing this issue
> Call call = new Call(id, this.service, md, header, param, cellScanner, this,
> responder,
> totalRequestSize, traceInfo, this.addr);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (HBASE-14512) Cache UGI groups
[ https://issues.apache.org/jira/browse/HBASE-14512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-14512. Resolution: Fixed Committed the addendum to 0.98, branch-1.2, branch-1, and master > Cache UGI groups > > > Key: HBASE-14512 > URL: https://issues.apache.org/jira/browse/HBASE-14512 > Project: HBase > Issue Type: Bug > Components: Performance, security >Affects Versions: 1.2.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.2.0, 1.3.0, 0.98.17 > > Attachments: HBASE-14512-addendum-0.98.patch, HBASE-14512-v1.patch, > HBASE-14512-v2.patch, HBASE-14512-v3.patch, HBASE-14512-v4.patch, > HBASE-14512.patch > > > Right now every call gets a new User object. > We should keep the same user for the life of a connection. We should also > cache the group names. However we can't cache the groups for forever as that > would mean groups don't get refreshed every 5 mins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15075) Allow region split request to carry identification information
[ https://issues.apache.org/jira/browse/HBASE-15075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102616#comment-15102616 ] Mikhail Antonov commented on HBASE-15075: - Briefly looked at the patch, some thoughts / question (unless I'm missing something here).. We're maintaining now map of UUID->split plan in SplitNormalizationPlan in static map, would it be better to keep in in *RegionNormalizer instead? Also we're generating id here in #execute() call, and sending plan with attached UUID out, uuid is getting passed thru, but we don't really account whether issued plan failed or not? In other words, there should be a map of failedPlans, not (just) recent plans? > Allow region split request to carry identification information > -- > > Key: HBASE-15075 > URL: https://issues.apache.org/jira/browse/HBASE-15075 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.3.0 > > Attachments: 15075-v0.txt, 15075-v1.txt, 15075-v2.txt, > HBASE-15075.v2.patch, HBASE-15075.v3.patch, HBASE-15075.v4.patch, > HBASE-15075.v5.patch > > > During the process of improving region normalization feature, I found that if > region split request triggered by the execution of SplitNormalizationPlan > fails, there is no way of knowing whether the failed split originated from > region normalization. > The association of particular split request with outcome of split would give > RegionNormalizer information so that it can make better normalization > decisions in the subsequent invocations. > One approach is to embed metadata, such as a UUID, in SplitRequest which gets > passed through RegionStateTransitionContext when > RegionServerServices#reportRegionStateTransition() is called. > This way, RegionStateListener can be notified with the metadata (id of the > requester). > See discussion on dev mailing list > http://search-hadoop.com/m/YGbbCXdkivihp2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-14376) move hbase spark integration examples into their own module
[ https://issues.apache.org/jira/browse/HBASE-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102640#comment-15102640 ] Andrew Purtell edited comment on HBASE-14376 at 1/15/16 11:01 PM: -- I'm having some difficulties with Phoenix Spark integration due to dependencies and general Scala compiler crap* that I assume will bedevil HBase users once we have a Spark integration module as well. I strongly prefer holding spark/scala dependencies to one module, which furthermore may be optionally skipped during build, for the time being. * - Sometimes, if you have an optional dependency (as part of the transitive dependency set), Maven+Scala won't pull it in, the Scala compiler with synthesize a stub, this isn't sufficient for something, and the compiler will NPE. Might come up at any time as the set of transitive dependencies change. was (Author: apurtell): I'm having some difficulties with Phoenix Spark integration due to dependencies and general Scala compiler crap* that I assume will bedevil HBase users of Spark as well. I strongly prefer holding spark/scala dependencies to one module, which furthermore may be optionally skipped during build, for the time being. * - Sometimes, if you have an optional dependency (as part of the transitive dependency set), Maven+Scala won't pull it in, the Scala compiler with synthesize a stub, this isn't sufficient for something, and the compiler will NPE. Might come up at any time as the set of transitive dependencies change. > move hbase spark integration examples into their own module > --- > > Key: HBASE-14376 > URL: https://issues.apache.org/jira/browse/HBASE-14376 > Project: HBase > Issue Type: Task > Components: pom, spark >Reporter: Sean Busbey >Assignee: Gabor Liptak > Labels: beginner > Attachments: HBASE-14376.1.patch, warnings.diff > > > take the examples that are currently in the hbase-spark module and move them > into a hbase-spark-examples module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-14376) move hbase spark integration examples into their own module
[ https://issues.apache.org/jira/browse/HBASE-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102640#comment-15102640 ] Andrew Purtell edited comment on HBASE-14376 at 1/15/16 11:03 PM: -- I'm having some difficulties with Phoenix Spark integration due to dependencies and general Scala compiler crap* that I assume will bedevil HBase users once we have a Spark integration module as well. I strongly prefer holding spark/scala dependencies to one module, which furthermore may be optionally skipped during build, for the time being. * - Sometimes, if you have an optional dependency (as part of the transitive dependency set), Maven+Scala won't pull it in, the Scala compiler will synthesize a stub, this isn't sufficient for something, and the compiler will NPE. At least 2.10.3 and 2.10.4 versions of the compiler have this problem. Might come up at any time as the set of transitive dependencies change. was (Author: apurtell): I'm having some difficulties with Phoenix Spark integration due to dependencies and general Scala compiler crap* that I assume will bedevil HBase users once we have a Spark integration module as well. I strongly prefer holding spark/scala dependencies to one module, which furthermore may be optionally skipped during build, for the time being. * - Sometimes, if you have an optional dependency (as part of the transitive dependency set), Maven+Scala won't pull it in, the Scala compiler with synthesize a stub, this isn't sufficient for something, and the compiler will NPE. Might come up at any time as the set of transitive dependencies change. > move hbase spark integration examples into their own module > --- > > Key: HBASE-14376 > URL: https://issues.apache.org/jira/browse/HBASE-14376 > Project: HBase > Issue Type: Task > Components: pom, spark >Reporter: Sean Busbey >Assignee: Gabor Liptak > Labels: beginner > Attachments: HBASE-14376.1.patch, warnings.diff > > > take the examples that are currently in the hbase-spark module and move them > into a hbase-spark-examples module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14376) move hbase spark integration examples into their own module
[ https://issues.apache.org/jira/browse/HBASE-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102689#comment-15102689 ] Appy commented on HBASE-14376: -- bq. I strongly prefer holding spark/scala dependencies to one module, which furthermore may be optionally skipped during build, for the time being. Just to clarify, do you not want them merged with hbase-examples, or, not be split at all (until dependency issues are fixed)? On a separate note, am a bit interested in knowing and following these dependency issues and see how they are fixed, any way that possible [~andrew.purt...@gmail.com]? > move hbase spark integration examples into their own module > --- > > Key: HBASE-14376 > URL: https://issues.apache.org/jira/browse/HBASE-14376 > Project: HBase > Issue Type: Task > Components: pom, spark >Reporter: Sean Busbey >Assignee: Gabor Liptak > Labels: beginner > Attachments: HBASE-14376.1.patch, warnings.diff > > > take the examples that are currently in the hbase-spark module and move them > into a hbase-spark-examples module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14865) Support passing multiple QOPs to SaslClient/Server via hbase.rpc.protection
[
https://issues.apache.org/jira/browse/HBASE-14865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Appy updated HBASE-14865:
-
Release Note:
With this patch, hbase.rpc.protection can now take multiple comma-separate QOP
values. Accepted QOP values remain unchanged and are 'authentication',
'integrity', and 'privacy'. While negotiating QOP, preference order used is
left-to-right.
This feature can be used to upgrade or downgrade QOP in an online cluster
without compromising availability (i.e. taking cluster offline). For e.g. to
change qop from A to B, typical steps would be:
"A" --> "B,A" --> rolling restart --> "B" --> rolling restart
> Support passing multiple QOPs to SaslClient/Server via hbase.rpc.protection
> ---
>
> Key: HBASE-14865
> URL: https://issues.apache.org/jira/browse/HBASE-14865
> Project: HBase
> Issue Type: Improvement
> Components: security
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0
>
> Attachments: 14865-master-v7.patch, HBASE-14865-branch-1.2.patch,
> HBASE-14865-branch-1.patch, HBASE-14865-branch-1.patch,
> HBASE-14865-master-v2.patch, HBASE-14865-master-v3.patch,
> HBASE-14865-master-v4.patch, HBASE-14865-master-v5.patch,
> HBASE-14865-master-v6.patch, HBASE-14865-master-v7.patch,
> HBASE-14865-master.patch
>
>
> Currently, we can set the value of hbase.rpc.protection to one of
> authentication/integrity/privacy. It is the used to set
> {{javax.security.sasl.qop}} in SaslUtil.java.
> The problem is, if a cluster wants to switch from one qop to another, it'll
> have to take a downtime. Rolling upgrade will create a situation where some
> nodes have old value and some have new, which'll prevent any communication
> between them. There will be similar issue when clients will try to connect.
> {{javax.security.sasl.qop}} can take in a list of QOP in preferences order.
> So a transition from qop1 to qop2 can be easily done like this
> "qop1" --> "qop2,qop1" --> rolling restart --> "qop2" --> rolling restart
> Need to change hbase.rpc.protection to accept a list too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14865) Support passing multiple QOPs to SaslClient/Server via hbase.rpc.protection
[
https://issues.apache.org/jira/browse/HBASE-14865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Appy updated HBASE-14865:
-
Release Note:
With this patch, hbase.rpc.protection can now take multiple comma-separate QOP
values. Accepted QOP values remain unchanged and are 'authentication',
'integrity', and 'privacy'. Server or client can use this configuration to
specify their preference (in decreasing order) while negotiating QOP.
This feature can be used to upgrade or downgrade QOP in an online cluster
without compromising availability (i.e. taking cluster offline). For e.g. to
change qop from A to B, typical steps would be:
"A" --> "B,A" --> rolling restart --> "B" --> rolling restart
Sidenote: Based on experimentation, server's choice is given higher preference
than client's choice. i.e. if server's choices are "A,B,C" and client's choices
are "B,C,A", both A and B are acceptable, but A is chosen.
was:
With this patch, hbase.rpc.protection can now take multiple comma-separate QOP
values. Accepted QOP values remain unchanged and are 'authentication',
'integrity', and 'privacy'. While negotiating QOP, preference order used is
left-to-right.
This feature can be used to upgrade or downgrade QOP in an online cluster
without compromising availability (i.e. taking cluster offline). For e.g. to
change qop from A to B, typical steps would be:
"A" --> "B,A" --> rolling restart --> "B" --> rolling restart
> Support passing multiple QOPs to SaslClient/Server via hbase.rpc.protection
> ---
>
> Key: HBASE-14865
> URL: https://issues.apache.org/jira/browse/HBASE-14865
> Project: HBase
> Issue Type: Improvement
> Components: security
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0
>
> Attachments: 14865-master-v7.patch, HBASE-14865-branch-1.2.patch,
> HBASE-14865-branch-1.patch, HBASE-14865-branch-1.patch,
> HBASE-14865-master-v2.patch, HBASE-14865-master-v3.patch,
> HBASE-14865-master-v4.patch, HBASE-14865-master-v5.patch,
> HBASE-14865-master-v6.patch, HBASE-14865-master-v7.patch,
> HBASE-14865-master.patch
>
>
> Currently, we can set the value of hbase.rpc.protection to one of
> authentication/integrity/privacy. It is the used to set
> {{javax.security.sasl.qop}} in SaslUtil.java.
> The problem is, if a cluster wants to switch from one qop to another, it'll
> have to take a downtime. Rolling upgrade will create a situation where some
> nodes have old value and some have new, which'll prevent any communication
> between them. There will be similar issue when clients will try to connect.
> {{javax.security.sasl.qop}} can take in a list of QOP in preferences order.
> So a transition from qop1 to qop2 can be easily done like this
> "qop1" --> "qop2,qop1" --> rolling restart --> "qop2" --> rolling restart
> Need to change hbase.rpc.protection to accept a list too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15075) Allow region split request to carry identification information
[ https://issues.apache.org/jira/browse/HBASE-15075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15075: --- Attachment: HBASE-15075.v7.patch > Allow region split request to carry identification information > -- > > Key: HBASE-15075 > URL: https://issues.apache.org/jira/browse/HBASE-15075 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.3.0 > > Attachments: 15075-v0.txt, 15075-v1.txt, 15075-v2.txt, > HBASE-15075.v2.patch, HBASE-15075.v3.patch, HBASE-15075.v4.patch, > HBASE-15075.v5.patch, HBASE-15075.v6.patch, HBASE-15075.v7.patch > > > During the process of improving region normalization feature, I found that if > region split request triggered by the execution of SplitNormalizationPlan > fails, there is no way of knowing whether the failed split originated from > region normalization. > The association of particular split request with outcome of split would give > RegionNormalizer information so that it can make better normalization > decisions in the subsequent invocations. > One approach is to embed metadata, such as a UUID, in SplitRequest which gets > passed through RegionStateTransitionContext when > RegionServerServices#reportRegionStateTransition() is called. > This way, RegionStateListener can be notified with the metadata (id of the > requester). > See discussion on dev mailing list > http://search-hadoop.com/m/YGbbCXdkivihp2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14969) Add throughput controller for flush
[
https://issues.apache.org/jira/browse/HBASE-14969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102910#comment-15102910
]
Duo Zhang commented on HBASE-14969:
---
In general, since we have a new package 'controller' and flush related
controller classes are put in that package, I suggest we also move compaction
related controller classes into that package. And I think the package name
should be ‘throttle’? The reason I chose the name 'ThroughputController' is
that there is already a 'throttle' when selecting thread pool when doing
compaction. But 'controller' usually leads people to the scope of MVC, so I
think we should use 'throttle' here.
And do we need two different {{NoLimitThroughputController}} for flush and
compaction? I do not think it is worth introducing two classes with only
different {{toString}} methods...
The whole patch looks good to me, no big concerns.
Thanks.
> Add throughput controller for flush
> ---
>
> Key: HBASE-14969
> URL: https://issues.apache.org/jira/browse/HBASE-14969
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-14969.patch, HBASE-14969_v2.patch,
> HBASE-14969_v3.patch, HBASE-14969_v4.patch, HBASE-14969_v5.patch,
> HBASE-14969_v6.patch, load-nothrottling.log, load-throttling.log
>
>
> In HBASE-8329 we added a throughput controller for compaction, to avoid spike
> caused by huge IO pressure like network/disk overflow. However, even with
> this control on, we are still observing disk utils near 100%, and by analysis
> we think this is caused by flush, especially when we increase the setting of
> {{hbase.hstore.flusher.count}}
> In this JIRA, we propose to add throughput control feature for flush, as a
> supplement of HBASE-8329 to better control IO pressure.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (HBASE-15110) update ref guide to list Hadoop 1.0 as NT for hbase 0.94
[ https://issues.apache.org/jira/browse/HBASE-15110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl reassigned HBASE-15110: - Assignee: Lars Hofhansl > update ref guide to list Hadoop 1.0 as NT for hbase 0.94 > > > Key: HBASE-15110 > URL: https://issues.apache.org/jira/browse/HBASE-15110 > Project: HBase > Issue Type: Bug > Components: documentation >Affects Versions: 0.94.28 >Reporter: Sean Busbey >Assignee: Lars Hofhansl > Fix For: 0.94.28 > > > right now the ref guide lists Hadoop 1.0 as "X" for hbase 0.94. the 0.94 > version of the book listed it as "S". > It's also the default version used in the 0.94 pom, so we should update the > ref guide to show it as a minimum of NT. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15075) Allow region split request to carry identification information
[ https://issues.apache.org/jira/browse/HBASE-15075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102632#comment-15102632 ] Ted Yu commented on HBASE-15075: For #1, currently the role of RegionNormalizer is that it feeds NormalizationPlan's to master. Master will execute the plans. The plan execution doesn't involve RegionNormalizer. That's why the map is a field of SplitNormalizationPlan. RegionNormalizer would still have access to this information. For #2, there should be a map of failedPlans. Can this be done in follow-on JIRA ? This JIRA provides plumbing for associating split request with Id of the requester. Thanks for the comments. > Allow region split request to carry identification information > -- > > Key: HBASE-15075 > URL: https://issues.apache.org/jira/browse/HBASE-15075 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.3.0 > > Attachments: 15075-v0.txt, 15075-v1.txt, 15075-v2.txt, > HBASE-15075.v2.patch, HBASE-15075.v3.patch, HBASE-15075.v4.patch, > HBASE-15075.v5.patch > > > During the process of improving region normalization feature, I found that if > region split request triggered by the execution of SplitNormalizationPlan > fails, there is no way of knowing whether the failed split originated from > region normalization. > The association of particular split request with outcome of split would give > RegionNormalizer information so that it can make better normalization > decisions in the subsequent invocations. > One approach is to embed metadata, such as a UUID, in SplitRequest which gets > passed through RegionStateTransitionContext when > RegionServerServices#reportRegionStateTransition() is called. > This way, RegionStateListener can be notified with the metadata (id of the > requester). > See discussion on dev mailing list > http://search-hadoop.com/m/YGbbCXdkivihp2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15046) Perf test doing all mutation steps under row lock
[ https://issues.apache.org/jira/browse/HBASE-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15046: -- Attachment: compare.png bq. We might be able to get that 5% back by going with the complexity of rollbacks on the default doMiniBatchMutation code path. Say more [~eclark] Turns out I had my graphs reversed. Perf is effectively the same with the patched version being perhaps slightly better and for sure better when just Gets. I reran it a few times. Let me try another, more direct test to be sure. This patch might be back alive. > Perf test doing all mutation steps under row lock > - > > Key: HBASE-15046 > URL: https://issues.apache.org/jira/browse/HBASE-15046 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack > Attachments: 1.2.svg, 1.2.v2.svg, 50threads_ycsb.png, > all_under_lock.patch, all_under_lock.svg, call_times_0-1_and_1-3_ycsb.png, > compare.png, gc.png, latencies.png, ops.png, writes.png > > > This issue is about perf testing a redo of the write pipeline so that rather > than: > * take rowlock > * start mvcc > * append to WAL > * add to memstore > * sync WAL > * let go of rowlock > * finish up mvcc > instead try... > * take rowlock > * start mvcc > * append to WAL > * sync WAL > * add to memstore > * finish up mvcc > * let go of rowlock > The latter is more straight-forward undoing need of rolling back memstore if > all does not succeed. > It might be slower though. This issue is a look-see/try it. > The redo will also help address the parent issue in a more general way so we > can do without the special-casing done for branch-1.0 and branch-1.1 done in > a sibling subtask. > Other benefits are that the current write pipeline is copy/pasted in a few > places -- in append, increment and checkand* -- and a refactor will allow us > to fix this duplication. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15075) Allow region split request to carry identification information
[ https://issues.apache.org/jira/browse/HBASE-15075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102767#comment-15102767 ] Mikhail Antonov commented on HBASE-15075: - I'd say if we need to have structure to keep track of failed plans, we may not need to have recent plans? I think logic inside region normalizer or master to actually use failedPlans data structure could be implemented in another jira, but it may be good to have this structure itself populated in this one, so we better who who and how keeps and updates failed plans, what do you think? API-wise, setRegionStateListener should be renamed to add* now? Why do we need this as part of this patch btw? > Allow region split request to carry identification information > -- > > Key: HBASE-15075 > URL: https://issues.apache.org/jira/browse/HBASE-15075 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.3.0 > > Attachments: 15075-v0.txt, 15075-v1.txt, 15075-v2.txt, > HBASE-15075.v2.patch, HBASE-15075.v3.patch, HBASE-15075.v4.patch, > HBASE-15075.v5.patch, HBASE-15075.v6.patch > > > During the process of improving region normalization feature, I found that if > region split request triggered by the execution of SplitNormalizationPlan > fails, there is no way of knowing whether the failed split originated from > region normalization. > The association of particular split request with outcome of split would give > RegionNormalizer information so that it can make better normalization > decisions in the subsequent invocations. > One approach is to embed metadata, such as a UUID, in SplitRequest which gets > passed through RegionStateTransitionContext when > RegionServerServices#reportRegionStateTransition() is called. > This way, RegionStateListener can be notified with the metadata (id of the > requester). > See discussion on dev mailing list > http://search-hadoop.com/m/YGbbCXdkivihp2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14877) maven archetype: client application
[ https://issues.apache.org/jira/browse/HBASE-14877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102766#comment-15102766 ] Daniel Vimont commented on HBASE-14877: --- Thanks for confirming my suspicions re: the findbugs "failures". In the latest precommit-build-output (build #142, just above this comment), it was run through the now-notorious *machine H2*, and so received the predictable (and hopefully bogus) failure notifications on all hadoopcheck steps. Thus, as far as I can see, this patch is ready for review by the powers-that-be for a potential commit through to the master branch*. (Although before that it might be nice to see a precommit run with all the hadoopcheck steps displayed in a pleasant shade of green.) *I would appreciate it if all who review this patch could do a thoughtful reading of the README.txt file that the patch inserts into the new hbase/hbase-archetypes subdirectory, since this patch introduces (and "commits" us to) a new infrastructure for creation and maintenance of our Maven archetypes into the future. I intentionally tried to keep the README text short and to-the-point, and I do not explain my rationale for setting things up the way I did. So feel free to ask for clarification of any aspect of the new infrastructure. (If this needs to be opened up for a broader discussion on the developers mailing-list, then that would be great.) > maven archetype: client application > --- > > Key: HBASE-14877 > URL: https://issues.apache.org/jira/browse/HBASE-14877 > Project: HBase > Issue Type: Sub-task > Components: build, Usability >Affects Versions: 2.0.0 >Reporter: Nick Dimiduk >Assignee: Daniel Vimont > Labels: archetype, beginner, maven > Attachments: HBASE-14877-v2.patch, HBASE-14877-v3.patch, > HBASE-14877.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15114) NPE when IPC server ByteBuffer reservoir is turned off
[
https://issues.apache.org/jira/browse/HBASE-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-15114:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Pushed this.
> NPE when IPC server ByteBuffer reservoir is turned off
> ---
>
> Key: HBASE-15114
> URL: https://issues.apache.org/jira/browse/HBASE-15114
> Project: HBase
> Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: hbase-15114.patch
>
>
> I was testing something else, and discovered that if we turn off the ipc
> out-buffer reservoir, we are getting NPEs after HBASE-14942.
> {code}
> 2016-01-14 15:29:35,865 WARN
> [PriorityRpcServer.handler=10,queue=0,port=16020] ipc.RpcServer:
> PriorityRpcServer.handler=10,queue=0,port=16020: caught:
> java.lang.NullPointerException
> at org.apache.hadoop.hbase.ipc.RpcServer$Call.done(RpcServer.java:358)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.processResponse(RpcServer.java:1159)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.doRespond(RpcServer.java:1209)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Call.sendResponseIfReady(RpcServer.java:574)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:135)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14512) Cache UGI groups
[ https://issues.apache.org/jira/browse/HBASE-14512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14512: --- Attachment: HBASE-14512-addendum-0.98.patch Addendum adds a null check for 'connection' when constructing a RpcServer#Call. Patch based on 0.98 but the change is the same everywhere. > Cache UGI groups > > > Key: HBASE-14512 > URL: https://issues.apache.org/jira/browse/HBASE-14512 > Project: HBase > Issue Type: Bug > Components: Performance, security >Affects Versions: 1.2.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.2.0, 1.3.0, 0.98.17 > > Attachments: HBASE-14512-addendum-0.98.patch, HBASE-14512-v1.patch, > HBASE-14512-v2.patch, HBASE-14512-v3.patch, HBASE-14512-v4.patch, > HBASE-14512.patch > > > Right now every call gets a new User object. > We should keep the same user for the life of a connection. We should also > cache the group names. However we can't cache the groups for forever as that > would mean groups don't get refreshed every 5 mins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (HBASE-14512) Cache UGI groups
[ https://issues.apache.org/jira/browse/HBASE-14512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell reopened HBASE-14512: This change will cause Phoenix's PhoenixIndexRpcSchedulerTest to fail with a NPE. There is something very simple (and correct) we can do as an addendum to fix it. Attaching the addendum. Unless objection will commit the addendum to all branches that have this change shortly, to get the 0.98 RC out the door. > Cache UGI groups > > > Key: HBASE-14512 > URL: https://issues.apache.org/jira/browse/HBASE-14512 > Project: HBase > Issue Type: Bug > Components: Performance, security >Affects Versions: 1.2.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.2.0, 1.3.0, 0.98.17 > > Attachments: HBASE-14512-v1.patch, HBASE-14512-v2.patch, > HBASE-14512-v3.patch, HBASE-14512-v4.patch, HBASE-14512.patch > > > Right now every call gets a new User object. > We should keep the same user for the life of a connection. We should also > cache the group names. However we can't cache the groups for forever as that > would mean groups don't get refreshed every 5 mins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-9393) Hbase does not closing a closed socket resulting in many CLOSE_WAIT
[ https://issues.apache.org/jira/browse/HBASE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102971#comment-15102971 ] Ashish Singhi commented on HBASE-9393: -- bq. The timeout that I'm talking about is inside DFSClient.java, not inside HBase. HDFS-4911 fixed a problem where the timeout was too long. I have experimented with all those configurations but the thing to note here is HBase is not closing the stream, so how will the socket will be closed. bq. Can you be a little bit clearer on what you'd like to implement, and what you see as the problem here? Below is the brief idea what I would like to implement, HBase will have a periodic thread monitoring these streams. When a stream is idle for more than configurable time, crossed the configurable limit on the maximum number of streams that can be kept open and has 0 references (like when HFile#pickReaderVersion is called I will increment the reference count and at the end I will decrement it, as after that this stream is no longer used in the same flow) to it then this thread will close that stream. The above implementation will be configurable and by default disabled as we are expecting some impact on read flow. > Hbase does not closing a closed socket resulting in many CLOSE_WAIT > > > Key: HBASE-9393 > URL: https://issues.apache.org/jira/browse/HBASE-9393 > Project: HBase > Issue Type: Bug >Affects Versions: 0.94.2, 0.98.0 > Environment: Centos 6.4 - 7 regionservers/datanodes, 8 TB per node, > 7279 regions >Reporter: Avi Zrachya > > HBase dose not close a dead connection with the datanode. > This resulting in over 60K CLOSE_WAIT and at some point HBase can not connect > to the datanode because too many mapped sockets from one host to another on > the same port. > The example below is with low CLOSE_WAIT count because we had to restart > hbase to solve the porblem, later in time it will incease to 60-100K sockets > on CLOSE_WAIT > [root@hd2-region3 ~]# netstat -nap |grep CLOSE_WAIT |grep 21592 |wc -l > 13156 > [root@hd2-region3 ~]# ps -ef |grep 21592 > root 17255 17219 0 12:26 pts/000:00:00 grep 21592 > hbase21592 1 17 Aug29 ?03:29:06 > /usr/java/jdk1.6.0_26/bin/java -XX:OnOutOfMemoryError=kill -9 %p -Xmx8000m > -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode > -Dhbase.log.dir=/var/log/hbase > -Dhbase.log.file=hbase-hbase-regionserver-hd2-region3.swnet.corp.log ... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15065) SimpleRegionNormalizer should return multiple normalization plans in one run
[ https://issues.apache.org/jira/browse/HBASE-15065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102621#comment-15102621 ] Ted Yu commented on HBASE-15065: Yes, we should. Do we use number of regions in transition as a metric for throttling decision making ? Any suggestion ? > SimpleRegionNormalizer should return multiple normalization plans in one run > > > Key: HBASE-15065 > URL: https://issues.apache.org/jira/browse/HBASE-15065 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: 15065-v1.txt, 15065-v2.txt, 15065.addendum > > > This is follow up to HBASE-14867 w.r.t. SimpleRegionNormalizer > Outline for enhancements: > * adjustment to the period when SimpleRegionNormalizer runs > * explore merge opportunities among all neighboring region pairs > * return multiple normalization plans -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14167) hbase-spark integration tests do not respect -DskipIntegrationTests
[
https://issues.apache.org/jira/browse/HBASE-14167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102650#comment-15102650
]
Andrew Purtell commented on HBASE-14167:
bq. I agree that the skipITs profile should just cause the second execution to
be skipped.
Great, this works for me too
> hbase-spark integration tests do not respect -DskipIntegrationTests
> ---
>
> Key: HBASE-14167
> URL: https://issues.apache.org/jira/browse/HBASE-14167
> Project: HBase
> Issue Type: Improvement
> Components: pom, spark
>Affects Versions: 2.0.0
>Reporter: Andrew Purtell
>Assignee: Gabor Liptak
>Priority: Minor
> Attachments: HBASE-14167-master-v2.patch, HBASE-14167.11.patch
>
>
> When running a build with {{mvn ... -DskipIntegrationTests}}, the hbase-spark
> module's integration tests do not respect the flag and run anyway. Fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15075) Allow region split request to carry identification information
[ https://issues.apache.org/jira/browse/HBASE-15075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15075: --- Attachment: HBASE-15075.v6.patch Patch v6 addresses Mikhail's comment on review board. > Allow region split request to carry identification information > -- > > Key: HBASE-15075 > URL: https://issues.apache.org/jira/browse/HBASE-15075 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.3.0 > > Attachments: 15075-v0.txt, 15075-v1.txt, 15075-v2.txt, > HBASE-15075.v2.patch, HBASE-15075.v3.patch, HBASE-15075.v4.patch, > HBASE-15075.v5.patch, HBASE-15075.v6.patch > > > During the process of improving region normalization feature, I found that if > region split request triggered by the execution of SplitNormalizationPlan > fails, there is no way of knowing whether the failed split originated from > region normalization. > The association of particular split request with outcome of split would give > RegionNormalizer information so that it can make better normalization > decisions in the subsequent invocations. > One approach is to embed metadata, such as a UUID, in SplitRequest which gets > passed through RegionStateTransitionContext when > RegionServerServices#reportRegionStateTransition() is called. > This way, RegionStateListener can be notified with the metadata (id of the > requester). > See discussion on dev mailing list > http://search-hadoop.com/m/YGbbCXdkivihp2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14635) Reenable TestSnapshotCloneIndependence.testOnlineSnapshotDeleteIndependent
[
https://issues.apache.org/jira/browse/HBASE-14635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102779#comment-15102779
]
Appy commented on HBASE-14635:
--
So [~eclark] made couple of good changes in HBASE-14585. But we couldn't see if
those good changes fixed the test because the patch also introduced the
following error which made the test to fail and subsequently removed in
HBASE-14678.
{noformat}
if (!online) {
- admin.enableTable(localTableName);
+ tryDisable(admin, localTableName);
}
{noformat}
Naming is kind of confusing there, so wouldn't blame Elliott. :-)
This patch only fixes that part inside {{if (!online) }} and waits for the
table to come online.
Lets see if it behaves good now.
> Reenable TestSnapshotCloneIndependence.testOnlineSnapshotDeleteIndependent
> --
>
> Key: HBASE-14635
> URL: https://issues.apache.org/jira/browse/HBASE-14635
> Project: HBase
> Issue Type: Task
> Components: test
>Reporter: stack
>Assignee: Appy
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-14635-master-v2.patch, HBASE-14635-master.patch
>
>
> Was disabled in the parent issue because flakey. This issue is about
> reenabling it after figuring why its flakey.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15059) Allow 0.94 to compile against Hadoop 2.7.x
[
https://issues.apache.org/jira/browse/HBASE-15059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102894#comment-15102894
]
Sean Busbey commented on HBASE-15059:
-
yeah, it's just to set {{-DcompileSource=1.7}} if you want to run with Hadoop
2.7. It should include a warning about how this will mean the generated jars
won't be usable with jdk 6.
> Allow 0.94 to compile against Hadoop 2.7.x
> --
>
> Key: HBASE-15059
> URL: https://issues.apache.org/jira/browse/HBASE-15059
> Project: HBase
> Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 0.94.28
>
> Attachments: 15059-v2.txt, 15059.txt
>
>
> Currently HBase 0.94 cannot be compiled against Hadoop 2.7.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15101) Leaked References to StoreFile.Reader after HBASE-13082
[ https://issues.apache.org/jira/browse/HBASE-15101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102936#comment-15102936 ] Ted Yu commented on HBASE-15101: bq. not being preceded with close I think close() should be added for those places. I ran test suite with the above addition of close() and latest patch. Looks like there was no repeatable test failure. > Leaked References to StoreFile.Reader after HBASE-13082 > --- > > Key: HBASE-15101 > URL: https://issues.apache.org/jira/browse/HBASE-15101 > Project: HBase > Issue Type: Bug > Components: HFile, io >Affects Versions: 2.0.0 >Reporter: deepankar >Assignee: deepankar > Attachments: HBASE-15101-v1.patch, HBASE-15101-v2.patch, > HBASE-15101-v3.patch, HBASE-15101.patch > > > We observed this production that after a region server dies there are huge > number of hfiles in that region for the region server running the version > with HBASE-13082, In the doc it is given that it is expected to happen, but > we found a one place where scanners are not being closed. If the scanners are > not closed their references are not decremented and that is leading to the > issue of huge number of store files not being finalized > All I was able to find is in the selectScannersFrom, where we discard some of > the scanners and we are not closing them. I am attaching a patch for that. > Also to avoid these issues should the files that are done be logged and > finalized (moved to archive) as a part of region close operation. This will > solve any leaks that can happen and does not cause any dire consequences? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14213) Ensure ASF policy compliant headers and correct LICENSE and NOTICE files in artifacts for 0.94
[ https://issues.apache.org/jira/browse/HBASE-14213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102984#comment-15102984 ] Lars Hofhansl commented on HBASE-14213: --- [~busbey] do you have the 2.7 changes you mentioned? Happy to test them out. > Ensure ASF policy compliant headers and correct LICENSE and NOTICE files in > artifacts for 0.94 > -- > > Key: HBASE-14213 > URL: https://issues.apache.org/jira/browse/HBASE-14213 > Project: HBase > Issue Type: Task > Components: build >Reporter: Nick Dimiduk >Assignee: Sean Busbey >Priority: Blocker > Fix For: 0.94.28 > > Attachments: 14213-LICENSE.txt, 14213-addendum.txt, > 14213-addendum2.txt, 14213-combined.txt, 14213-part1.txt, 14213-part2.txt, > 14213-part3.sh, 14213-part4.sh, 14213-part5.sh, HBASE-14213.1.0.94.patch > > > From tail of thread on HBASE-14085, opening a backport ticket for 0.94. Took > the liberty of assigning to [~busbey]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14962) TestSplitWalDataLoss fails on all branches
[
https://issues.apache.org/jira/browse/HBASE-14962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-14962:
--
Attachment: 14962.patch
Test gets RS and from here, it gets actual Region, doctors it so it can be
spied upon and then puts the spied upon Region back into RS list-of-regions.
This latter was being done by just getting the key of the 'first region'.
Sometimes the latter was hbase:meta.
> TestSplitWalDataLoss fails on all branches
> --
>
> Key: HBASE-14962
> URL: https://issues.apache.org/jira/browse/HBASE-14962
> Project: HBase
> Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: 14962.patch,
> org.apache.hadoop.hbase.regionserver.TestSplitWalDataLoss-output.txt,
> org.apache.hadoop.hbase.regionserver.TestSplitWalDataLoss-output.txt
>
>
> With some regularity I am seeing:
> {code}
> org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1
> action: TestSplitWalDataLoss:dataloss: 1 time,
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:228)
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$1800(AsyncProcess.java:208)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForAllPreviousOpsAndReset(AsyncProcess.java:1712)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.backgroundFlushCommits(BufferedMutatorImpl.java:240)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.flush(BufferedMutatorImpl.java:190)
> at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1430)
> at org.apache.hadoop.hbase.client.HTable.put(HTable.java:1021)
> at
> org.apache.hadoop.hbase.regionserver.TestSplitWalDataLoss.test(TestSplitWalDataLoss.java:121)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14962) TestSplitWalDataLoss fails on all branches
[
https://issues.apache.org/jira/browse/HBASE-14962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-14962:
--
Fix Version/s: 1.3.0
2.0.0
Status: Patch Available (was: Open)
> TestSplitWalDataLoss fails on all branches
> --
>
> Key: HBASE-14962
> URL: https://issues.apache.org/jira/browse/HBASE-14962
> Project: HBase
> Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: 14962.patch,
> org.apache.hadoop.hbase.regionserver.TestSplitWalDataLoss-output.txt,
> org.apache.hadoop.hbase.regionserver.TestSplitWalDataLoss-output.txt
>
>
> With some regularity I am seeing:
> {code}
> org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1
> action: TestSplitWalDataLoss:dataloss: 1 time,
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:228)
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$1800(AsyncProcess.java:208)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForAllPreviousOpsAndReset(AsyncProcess.java:1712)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.backgroundFlushCommits(BufferedMutatorImpl.java:240)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.flush(BufferedMutatorImpl.java:190)
> at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1430)
> at org.apache.hadoop.hbase.client.HTable.put(HTable.java:1021)
> at
> org.apache.hadoop.hbase.regionserver.TestSplitWalDataLoss.test(TestSplitWalDataLoss.java:121)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15098) Normalizer switch in configuration is not used
[
https://issues.apache.org/jira/browse/HBASE-15098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-15098:
---
Release Note: The config parameter, hbase.normalizer.enabled, has been
dropped since it is not used in the code base.
> Normalizer switch in configuration is not used
> --
>
> Key: HBASE-15098
> URL: https://issues.apache.org/jira/browse/HBASE-15098
> Project: HBase
> Issue Type: Bug
> Components: master
>Affects Versions: 1.2.0
>Reporter: Lars George
>Priority: Blocker
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: HBASE-15098.v1.patch
>
>
> The newly added global switch to enable the new normalizer functionality is
> never used apparently, meaning it is always on. The {{hbase-default.xml}} has
> this:
> {noformat}
>
> hbase.normalizer.enabled
> false
> If set to true, Master will try to keep region size
> within each table approximately the same.
>
> {noformat}
> But only a test class uses it to set the switch to "true". We should
> implement a proper {{if}} statement that checks this value and properly
> disables the feature cluster wide if not wanted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14876) Provide maven archetypes
[ https://issues.apache.org/jira/browse/HBASE-14876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102721#comment-15102721 ] Daniel Vimont commented on HBASE-14876: --- It's in the "v3" patch just submitted to HBASE-14877 (the first child of this issue, which adds the hbase-archetypes infrastructure and the first archetype*). *The first archetype is for a simple hbase-client dependent application. > Provide maven archetypes > > > Key: HBASE-14876 > URL: https://issues.apache.org/jira/browse/HBASE-14876 > Project: HBase > Issue Type: New Feature > Components: build, Usability >Affects Versions: 2.0.0 >Reporter: Nick Dimiduk >Assignee: Daniel Vimont > Labels: beginner, maven > Attachments: HBASE-14876-v2.patch, HBASE-14876.patch, > archetype_prototype.zip, archetype_prototype02.zip, > archetype_shaded_prototype01.zip > > > To help onboard new users, we should provide maven archetypes for hbase > client applications. Off the top of my head, we should have templates for > - hbase client application with all dependencies > - hbase client application using client-shaded jar > - mapreduce application with hbase as input and output (ie, copy table) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15123) Remove duplicate code in LocalHBaseCluster and minor formatting
[ https://issues.apache.org/jira/browse/HBASE-15123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-15123: - Attachment: HBASE-15123-master-v1.patch > Remove duplicate code in LocalHBaseCluster and minor formatting > --- > > Key: HBASE-15123 > URL: https://issues.apache.org/jira/browse/HBASE-15123 > Project: HBase > Issue Type: Improvement >Reporter: Appy >Assignee: Appy >Priority: Minor > Attachments: HBASE-15123-master-v1.patch > > > Remove duplicate code in following overloaded functions of LocalHBaseCluster: > - waitOnMaster > - waitOnRegionServer > Also minor formatting changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
