date:20170118

[jira] [Commented] (HBASE-17289) Avoid adding a replication peer named "lock"

2017-01-18 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829488#comment-15829488
 ] 

Hudson commented on HBASE-17289:


FAILURE: Integrated in Jenkins build HBase-1.2-IT #584 (See 
[https://builds.apache.org/job/HBase-1.2-IT/584/])
HBASE-17289 Avoid adding a replication peer named lock (zghao: rev 
4778995c4eefa759b01fded7bf62aaa8953db5ed)
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/replication/ReplicationQueuesZKImpl.java
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/client/replication/TestReplicationAdmin.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/replication/ReplicationPeersZKImpl.java


> Avoid adding a replication peer named "lock"
> 
>
> Key: HBASE-17289
> URL: https://issues.apache.org/jira/browse/HBASE-17289
> Project: HBase
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 1.3.0, 1.4.0, 1.1.7, 0.98.23, 1.2.4
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 1.4.0, 1.3.1, 1.2.5, 1.1.9
>
> Attachments: HBASE-17289-branch-1.1.patch, 
> HBASE-17289-branch-1.2.patch, HBASE-17289-branch-1.3.patch, 
> HBASE-17289-branch-1.patch
>
>
> When zk based replication queue is used and useMulti is false, the steps of 
> transfer replication queues are first add a lock, then copy nodes, finally 
> clean old queue and the lock. And the default lock znode's name is "lock". So 
> we should avoid adding a peer named "lock". 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17165) Add retry to LoadIncrementalHFiles tool

2017-01-18 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829487#comment-15829487
 ] 

Hadoop QA commented on HBASE-17165:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 12m 34s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m 
8s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 31s 
{color} | {color:green} branch-1 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s 
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 
0s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
22s {color} | {color:green} branch-1 passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 54s 
{color} | {color:red} hbase-server in branch-1 has 2 extant Findbugs warnings. 
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 31s 
{color} | {color:green} branch-1 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s 
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 30s 
{color} | {color:green} the patch passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 30s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 36s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
54s {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} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
15m 1s {color} | {color:green} The 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} hbaseprotoc {color} | {color:green} 0m 
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 6s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s 
{color} | {color:green} the patch passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 112m 2s {color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
24s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 159m 19s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestHRegion |
|   | hadoop.hbase.client.TestMetaWithReplicas |
| Timed out junit tests | org.apache.hadoop.hbase.client.TestHCM |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.6 Server=1.12.6 Image:yetus/hbase:e01ee2f |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12848234/HBASE-17165.branch-1.001.patch
 |
| JIRA Issue | HBASE-17165 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 6c0ba5fc0e11 3.13.0-100-generic #147-Ubuntu SMP Tue Oct 18 
16:48:51 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool |

[jira] [Commented] (HBASE-17396) Add first async admin impl and implement balance methods

2017-01-18 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829466#comment-15829466
 ] 

Hudson commented on HBASE-17396:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #2345 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/2345/])
HBASE-17396 Add first async admin impl and implement balance methods (zghao: 
rev cb9ce2ceafb5467522b1b380956446e40b8250d5)
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncSingleRequestRpcRetryingCaller.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncConnection.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncRpcRetryingCallerFactory.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncConnectionImpl.java
* (add) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncHBaseAdmin.java
* (add) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncMasterRequestRpcRetryingCaller.java
* (add) 
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncAdmin.java
* (add) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncRpcRetryingCaller.java
* (add) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncAdmin.java


> Add first async admin impl and implement balance methods
> 
>
> Key: HBASE-17396
> URL: https://issues.apache.org/jira/browse/HBASE-17396
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-17396-v1.patch, HBASE-17396-v2.patch, 
> HBASE-17396-v3.patch, HBASE-17396-v4.patch, HBASE-17396-v5.patch, 
> HBASE-17396-v6.patch, HBASE-17396-v7.patch, HBASE-17396-v8.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17289) Avoid adding a replication peer named "lock"

2017-01-18 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829462#comment-15829462
 ] 

Hudson commented on HBASE-17289:


FAILURE: Integrated in Jenkins build HBase-1.1-JDK8 #1919 (See 
[https://builds.apache.org/job/HBase-1.1-JDK8/1919/])
HBASE-17289 Avoid adding a replication peer named lock (zghao: rev 
cc9b471e0eb511e4597874e945bfabc0905f7186)
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/replication/ReplicationQueuesZKImpl.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/replication/ReplicationPeersZKImpl.java
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/client/replication/TestReplicationAdmin.java


> Avoid adding a replication peer named "lock"
> 
>
> Key: HBASE-17289
> URL: https://issues.apache.org/jira/browse/HBASE-17289
> Project: HBase
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 1.3.0, 1.4.0, 1.1.7, 0.98.23, 1.2.4
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 1.4.0, 1.3.1, 1.2.5, 1.1.9
>
> Attachments: HBASE-17289-branch-1.1.patch, 
> HBASE-17289-branch-1.2.patch, HBASE-17289-branch-1.3.patch, 
> HBASE-17289-branch-1.patch
>
>
> When zk based replication queue is used and useMulti is false, the steps of 
> transfer replication queues are first add a lock, then copy nodes, finally 
> clean old queue and the lock. And the default lock znode's name is "lock". So 
> we should avoid adding a peer named "lock". 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0

2017-01-18 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829455#comment-15829455
 ] 

Hadoop QA commented on HBASE-16179:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m 3s 
{color} | {color:blue} The patch file was not named according to hbase's naming 
conventions. Please see 
https://yetus.apache.org/documentation/0.3.0/precommit-patchnames for 
instructions. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 9 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 22s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
23s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 44s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
33s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m 
36s {color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s 
{color} | {color:blue} Skipped patched modules with no Java source: 
hbase-assembly . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 
38s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 23s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 1m 
28s {color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 10m 
6s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m 46s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 9m 46s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} scalac {color} | {color:green} 9m 46s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 
4s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 3m 
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 12s 
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
48m 41s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s 
{color} | {color:blue} Skipped patched modules with no Java source: 
hbase-spark2.0-compat hbase-spark1.6-compat . hbase-assembly hbase-spark-1.6 
hbase-spark-1.6-scala-2.10 hbase-spark-scala-2.10 
hbase-spark1.6-compat-scala-2.10 hbase-spark2.0-compat-scala-2.10 {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 
42s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 2m 22s 
{color} | {color:red} root generated 55 new + 18 unchanged - 1 fixed = 73 total 
(was 19) {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 10s 
{color} | {color:red} hbase-spark generated 1 new + 17 unchanged - 1 fixed = 18 
total (was 18) {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 9s 
{color} | {color:red} hbase-spark-1.6 generated 18 new + 0 unchanged - 0 fixed 
= 18 total (was 0) {color} |
| {color:red}-1{color} | {color:red} javadoc

[jira] [Commented] (HBASE-16786) Procedure V2 - Move ZK-lock's uses to Procedure framework locks (LockProcedure)

2017-01-18 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-16786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829459#comment-15829459
 ] 

Hadoop QA commented on HBASE-16786:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 10s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 16 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 21s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 
54s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 53s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
25s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
29s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 45s 
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 9s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
0s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 56s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 56s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
30s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
25m 1s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 
36s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 47s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 26s 
{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 85m 3s 
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 25s 
{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
39s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 128m 52s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12848233/HBASE-16786.master.012.patch
 |
| JIRA Issue | HBASE-16786 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 44f1feb46809 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12 
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / cb9ce2c |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5327/testReport/ |
| modules | C: hbase-procedure hbase-server hbase-rsgroup U: . |
| Console output |

[jira] [Commented] (HBASE-17045) Unify the implementation of small scan and regular scan

2017-01-18 Thread Duo Zhang (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829442#comment-15829442
 ] 

Duo Zhang commented on HBASE-17045:
---

I think the close scanner automatically if no more results feature can be 
integrated in the patch of HBASE-17489.

Hope I could prepare a patch for HBASE-17489 before you wake up in the 
morning... [~stack]

> Unify the implementation of small scan and regular scan
> ---
>
> Key: HBASE-17045
> URL: https://issues.apache.org/jira/browse/HBASE-17045
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client, scan
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-17045.patch, HBASE-17045-v1.patch, 
> HBASE-17045-v2.patch, HBASE-17045-v3.patch, HBASE-17045-v4.patch, 
> HBASE-17045-v5.patch
>
>
> See [~enis]'s comment in HBASE-16838
> https://issues.apache.org/jira/browse/HBASE-16838?focusedCommentId=15637803=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15637803
> But there is another scenario that we need small scan is that, we do not know 
> the stop row but we only want a small set of results. For example, in the 
> implementation of region locator, we will use small scan and set caching to 1 
> as we only need one row.
> So I think we need to add a new option(maybe called limit?) for the scan 
> object, and deprecate the small option. And the server side modification 
> should also be committed to branch-1 to simplify the logic of async client in 
> 2.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17346) Add coprocessor service support

2017-01-18 Thread Duo Zhang (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829428#comment-15829428
 ] 

Duo Zhang commented on HBASE-17346:
---

The stubMaker and callable are just bridges to the generated protobuf code. A 
stubMaker is usually a {{XXXService.newStub(RpcChannel)}} method call, and the 
callable is usually a {{stub.xxx(RpcController, Message, RpcCallback)}} call. 
All the parameters will be prepared by us and user just need to pass them to 
the right method.
Yes it exposes some internals to user so that's why I just keep them in the 
RawAsyncTable interface. It should only be used by advanced users.

{quote}
The channel and controller we get from where? Ditto 'done' I don't see them in 
the aggregation class.
{quote}
See the RegionCoprocessorRpcChannelImpl class.

And for the callback, onRegionComplete is used to tell you that there is a 
result for a particular region, and onComplete is used to tell you that the 
operation is finished, i.e., there is no new onRegionComplete. This is because 
the region locator itself is also asynchronous, and I want to send actual 
request to region on the fly, i.e., send a request immediately after we get the 
location of a region without getting all the region and their locations. So we 
need to find a way to tell user that there is no region, that's why we have an 
onComplete method.

And the onError method is called when locating error. Typically onRegionError 
and onError have the same effect that you should fail the whole operation as we 
have already retried many times.

{quote}
You don't need PayloadCarryingRpcController here, right
{quote}
PCRC extends the shaded RpcController, we can not use it for coprocessor call...

Thanks.

> Add coprocessor service support
> ---
>
> Key: HBASE-17346
> URL: https://issues.apache.org/jira/browse/HBASE-17346
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client, Coprocessors
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: 17346.suggestion.txt, HBASE-17346.patch, 
> HBASE-17346-v1.patch
>
>
> I think we need to redesign the API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17471) Region Seqid will be out of order in WAL if using mvccPreAssign

2017-01-18 Thread Yu Li (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829425#comment-15829425
 ] 

Yu Li commented on HBASE-17471:
---

+1 on the fix. IIRC, [~enis] also mentioned not to include any configuration 
and make preassign the logic if it indeed improves performance, but I'm not 
quite sure whether it's true for append/increment in real world (though in 
theory I believe in this), so I guess more test and data need to be supplied.

I'm leaving HBASE-16698 open (sorry for a quite long time I'd say...) because I 
see some unstable performance number for ASYNC_WAL testing but didn't get time 
to confirm it later on. I guess you've done more testing in your environment 
[~allan163]? If so, mind share the data here? Thanks.

And have to admit that in our product scenarios we don't use any of 
append/increment request, so I didn't think of the problem described here. 
Thanks for pointing out the issue and trying hard to complete the work 
[~allan163].

> Region Seqid will be out of order in WAL if using mvccPreAssign
> ---
>
> Key: HBASE-17471
> URL: https://issues.apache.org/jira/browse/HBASE-17471
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Critical
> Attachments: HBASE-17471.patch, HBASE-17471.tmp
>
>
>  mvccPreAssign was brought by HBASE-16698, which truly improved the 
> performance of writing, especially in ASYNC_WAL scenario. But mvccPreAssign 
> was only used in {{doMiniBatchMutate}}, not in Increment/Append path. If 
> Increment/Append and batch put are using against the same region in parallel, 
> then seqid of the same region may not monotonically increasing in the WAL. 
> Since one write path acquires mvcc/seqid before append, and the other 
> acquires in the append/sync consume thread.
> The out of order situation can easily reproduced by a simple UT, which was 
> attached in the attachment. I modified the code to assert on the disorder: 
> {code}
> if(this.highestSequenceIds.containsKey(encodedRegionName)) {
>   assert highestSequenceIds.get(encodedRegionName) < sequenceid;
> }
> {code}
> I'd like to say, If we allow disorder in WALs, then this is not a issue. 
> But as far as I know, if {{highestSequenceIds}} is not properly set, some 
> WALs may not archive to oldWALs correctly.
> which I haven't figure out yet is that, will disorder in WAL cause data loss 
> when recovering from disaster? If so, then it is a big problem need to be 
> fixed.
> I have fix this problem in our costom1.1.x branch, my solution is using 
> mvccPreAssign everywhere, making it un-configurable. Since mvccPreAssign it 
> is indeed a better way than assign seqid in the ringbuffer thread while 
> keeping handlers waiting for it.
> If anyone think it is doable, then I will port it to branch-1 and master 
> branch and upload it. 
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread ChiaPing Tsai (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ChiaPing Tsai updated HBASE-17488:
--
Release Note: 
prevent creating unused objects in the WALEdit's construction.
+If the cp#preBatchMutate returns true, the WALEdit is useless. So we should 
create the WALEdit after step 2.
+The cells came from cp should be counted because they are added into the 
WALEdit . The use case is the local index of phoenix
+If the mutation contains the SKIP_WAL property, its cells aren't added into 
the WALEdit. So these cells shouldn't be counted.

> WALEdit should be lazily instantiated
> -
>
> Key: HBASE-17488
> URL: https://issues.apache.org/jira/browse/HBASE-17488
> Project: HBase
>  Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Trivial
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17488.branch-1.v0.patch, 
> HBASE-17488.branch-1.v0.patch
>
>
> Some trivial improvement.
> # create the WALEdit on step 3 instead of step 2
> # count the cells from coprocessor
> # don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread ChiaPing Tsai (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829420#comment-15829420
 ] 

ChiaPing Tsai commented on HBASE-17488:
---

bq. You have a patch for master branch?
Yes, i will attach the patch for master after the QA

> WALEdit should be lazily instantiated
> -
>
> Key: HBASE-17488
> URL: https://issues.apache.org/jira/browse/HBASE-17488
> Project: HBase
>  Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Trivial
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17488.branch-1.v0.patch, 
> HBASE-17488.branch-1.v0.patch
>
>
> Some trivial improvement.
> # create the WALEdit on step 3 instead of step 2
> # count the cells from coprocessor
> # don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread stack (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-17488:
--
Attachment: HBASE-17488.branch-1.v0.patch

Retry

You have a patch for master branch [~chia7712]? thanks.

> WALEdit should be lazily instantiated
> -
>
> Key: HBASE-17488
> URL: https://issues.apache.org/jira/browse/HBASE-17488
> Project: HBase
>  Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Trivial
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17488.branch-1.v0.patch, 
> HBASE-17488.branch-1.v0.patch
>
>
> Some trivial improvement.
> # create the WALEdit on step 3 instead of step 2
> # count the cells from coprocessor
> # don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829414#comment-15829414
 ] 

stack commented on HBASE-17488:
---

Thanks [~chia7712] Above would serve as nice release note. +1 on patch.

> WALEdit should be lazily instantiated
> -
>
> Key: HBASE-17488
> URL: https://issues.apache.org/jira/browse/HBASE-17488
> Project: HBase
>  Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Trivial
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17488.branch-1.v0.patch
>
>
> Some trivial improvement.
> # create the WALEdit on step 3 instead of step 2
> # count the cells from coprocessor
> # don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17045) Unify the implementation of small scan and regular scan

2017-01-18 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829411#comment-15829411
 ] 

stack commented on HBASE-17045:
---

Took a quick look. Let me come back w/ some substance [~Apache9] in morning.

> Unify the implementation of small scan and regular scan
> ---
>
> Key: HBASE-17045
> URL: https://issues.apache.org/jira/browse/HBASE-17045
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client, scan
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-17045.patch, HBASE-17045-v1.patch, 
> HBASE-17045-v2.patch, HBASE-17045-v3.patch, HBASE-17045-v4.patch, 
> HBASE-17045-v5.patch
>
>
> See [~enis]'s comment in HBASE-16838
> https://issues.apache.org/jira/browse/HBASE-16838?focusedCommentId=15637803=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15637803
> But there is another scenario that we need small scan is that, we do not know 
> the stop row but we only want a small set of results. For example, in the 
> implementation of region locator, we will use small scan and set caching to 1 
> as we only need one row.
> So I think we need to add a new option(maybe called limit?) for the scan 
> object, and deprecate the small option. And the server side modification 
> should also be committed to branch-1 to simplify the logic of async client in 
> 2.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread ChiaPing Tsai (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829410#comment-15829410
 ] 

ChiaPing Tsai commented on HBASE-17488:
---

hi [~stack]
bq. What sort of benefit do you expect
prevent creating unused objects in the WALEdit's construction.

# If the cp#preBatchMutate returns true, the WALEdit is useless. So we should 
create the WALEdit after step 2.
# The cells came from cp should be counted because they are added into the 
WALEdit . The use case is the local index of phoenix 
# If the mutation contains the SKIP_WAL property, its cells aren't added into 
the WALEdit. So these cells shouldn't be counted.

> WALEdit should be lazily instantiated
> -
>
> Key: HBASE-17488
> URL: https://issues.apache.org/jira/browse/HBASE-17488
> Project: HBase
>  Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Trivial
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17488.branch-1.v0.patch
>
>
> Some trivial improvement.
> # create the WALEdit on step 3 instead of step 2
> # count the cells from coprocessor
> # don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17045) Unify the implementation of small scan and regular scan

2017-01-18 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829406#comment-15829406
 ] 

Hadoop QA commented on HBASE-17045:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} 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 6 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 26s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
46s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 57s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m 
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
41s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 11s 
{color} | {color:red} hbase-protocol-shaded in master has 24 extant Findbugs 
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 6s 
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 
5s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 55s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 55s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 55s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m 
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
42s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
30m 6s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 1m 
35s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 8m 
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 7s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 20s 
{color} | {color:green} hbase-protocol in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 34s 
{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 1m 13s {color} 
| {color:red} hbase-client in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 101m 10s 
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
58s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 178m 49s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.TestInterfaceAudienceAnnotations |
| Timed out junit tests | org.apache.hadoop.hbase.client.TestAsyncTableBatch |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12848219/HBASE-17045-v5.patch |
| JIRA Issue | HBASE-17045 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti

[jira] [Commented] (HBASE-17289) Avoid adding a replication peer named "lock"

2017-01-18 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829405#comment-15829405
 ] 

Hudson commented on HBASE-17289:


FAILURE: Integrated in Jenkins build HBase-1.3-IT #818 (See 
[https://builds.apache.org/job/HBase-1.3-IT/818/])
HBASE-17289 Avoid adding a replication peer named lock (zghao: rev 
4778995c4eefa759b01fded7bf62aaa8953db5ed)
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/client/replication/TestReplicationAdmin.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/replication/ReplicationPeersZKImpl.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/replication/ReplicationQueuesZKImpl.java


> Avoid adding a replication peer named "lock"
> 
>
> Key: HBASE-17289
> URL: https://issues.apache.org/jira/browse/HBASE-17289
> Project: HBase
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 1.3.0, 1.4.0, 1.1.7, 0.98.23, 1.2.4
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 1.4.0, 1.3.1, 1.2.5, 1.1.9
>
> Attachments: HBASE-17289-branch-1.1.patch, 
> HBASE-17289-branch-1.2.patch, HBASE-17289-branch-1.3.patch, 
> HBASE-17289-branch-1.patch
>
>
> When zk based replication queue is used and useMulti is false, the steps of 
> transfer replication queues are first add a lock, then copy nodes, finally 
> clean old queue and the lock. And the default lock znode's name is "lock". So 
> we should avoid adding a peer named "lock". 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17480) Remove split region code from Region Server

2017-01-18 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829404#comment-15829404
 ] 

stack commented on HBASE-17480:
---

+1

That is a nice lump of code removed.

You remove TestSplitTransaction. Do we have an explicit test of the splitting 
path any more post this removal? [~syuanjiang]

> Remove split region code from Region Server
> ---
>
> Key: HBASE-17480
> URL: https://issues.apache.org/jira/browse/HBASE-17480
> Project: HBase
>  Issue Type: Sub-task
>  Components: Region Assignment
>Affects Versions: 2.0.0
>Reporter: Stephen Yuan Jiang
>Assignee: Stephen Yuan Jiang
> Fix For: 2.0.0
>
> Attachments: HBASE-17480.v1-master.patch, HBASE-17480.v2-master.patch
>
>
> HBASE-14551 moves the split region logic to the master-side. With the code in 
> HBASE-14551, the split transaction code from region server side became 
> un-used.  There is no need to keep region_server-side split region code.  We 
> should remove them to avoid code duplication.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17346) Add coprocessor service support

2017-01-18 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829399#comment-15829399
 ] 

stack commented on HBASE-17346:
---

Looking...

Having a bit of trouble getting my head around it.

You expose more than what sync Table does.

I'm having trouble following this:

+table.coprocessorService(channel -> AggregateService.newStub(channel),
+  (stub, controller, done) -> stub.getMax(controller, req, done), 
scan.getStartRow(),
+  scan.includeStartRow(), scan.getStopRow(), scan.includeStopRow(), 
callback);
+return future;

The channel and controller we get from where? Ditto 'done' I don't see them in 
the aggregation class.

And then that AggregateService.newStub(channel) is a 'stubmaker' of this form: 
Function stubMaker

Name ClientCoprocessorRpcController more generic than 
ClientCoprocessorRpcController  I thought we'd made a basic RpcController in a 
few places in tests but looks like it is only the 
AggregationClientRpcController which looks like this (except it does 
'cancel'...)Name it BasicRpcController or SimpleRpcController since can be 
used for more than just CP?

This is nice:

  @FunctionalInterface

We have to expose RpcController in method signature?  We can't keep it 
internal? You thinking we'd expose the cancel/failed functionality via this 
RpcController?  Doesn't user have the CompleteableFuture to get this stuff out 
of the invocation? 

You don't need PayloadCarryingRpcController here, right...

So, the onRegionComplete and onComplete...  in CoprocessorCallback whats 
the diff? You get notification on completion of each of these steps?

Pardon dumb questions...







> Add coprocessor service support
> ---
>
> Key: HBASE-17346
> URL: https://issues.apache.org/jira/browse/HBASE-17346
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client, Coprocessors
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: 17346.suggestion.txt, HBASE-17346.patch, 
> HBASE-17346-v1.patch
>
>
> I think we need to redesign the API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17480) Remove split region code from Region Server

2017-01-18 Thread Stephen Yuan Jiang (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Yuan Jiang updated HBASE-17480:
---
Description: 
HBASE-14551 moves the split region logic to the master-side. With the code in 
HBASE-14551, the split transaction code from region server side became un-used. 
 There is no need to keep region_server-side split region code.  We should 
remove them to avoid code duplication.  


  was:
HBASE-14551 moves the split region logic to the master-side. With the code in 
HBASE-14551, the split transaction code became un-used.  There is no need to 
keep region_server-side split region code.  We should remove them to avoid code 
duplication.  



> Remove split region code from Region Server
> ---
>
> Key: HBASE-17480
> URL: https://issues.apache.org/jira/browse/HBASE-17480
> Project: HBase
>  Issue Type: Sub-task
>  Components: Region Assignment
>Affects Versions: 2.0.0
>Reporter: Stephen Yuan Jiang
>Assignee: Stephen Yuan Jiang
> Fix For: 2.0.0
>
> Attachments: HBASE-17480.v1-master.patch, HBASE-17480.v2-master.patch
>
>
> HBASE-14551 moves the split region logic to the master-side. With the code in 
> HBASE-14551, the split transaction code from region server side became 
> un-used.  There is no need to keep region_server-side split region code.  We 
> should remove them to avoid code duplication.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17480) Remove split region code from Region Server

2017-01-18 Thread Stephen Yuan Jiang (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Yuan Jiang updated HBASE-17480:
---
Description: 
HBASE-14551 moves the split region logic to the master-side. With the code in 
HBASE-14551, the split transaction code became un-used.  There is no need to 
keep region_server-side split region code.  We should remove them to avoid code 
duplication.  


  was:
HBASE-14551 moves the split region logic to the master-side. There is no need 
to keep region_server-side split region code.  We should remove them to avoid 
code duplication.



> Remove split region code from Region Server
> ---
>
> Key: HBASE-17480
> URL: https://issues.apache.org/jira/browse/HBASE-17480
> Project: HBase
>  Issue Type: Sub-task
>  Components: Region Assignment
>Affects Versions: 2.0.0
>Reporter: Stephen Yuan Jiang
>Assignee: Stephen Yuan Jiang
> Fix For: 2.0.0
>
> Attachments: HBASE-17480.v1-master.patch, HBASE-17480.v2-master.patch
>
>
> HBASE-14551 moves the split region logic to the master-side. With the code in 
> HBASE-14551, the split transaction code became un-used.  There is no need to 
> keep region_server-side split region code.  We should remove them to avoid 
> code duplication.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17480) Remove split region code from Region Server

2017-01-18 Thread Stephen Yuan Jiang (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829380#comment-15829380
 ] 

Stephen Yuan Jiang commented on HBASE-17480:


V2 patch fixed the UT failure.

> Remove split region code from Region Server
> ---
>
> Key: HBASE-17480
> URL: https://issues.apache.org/jira/browse/HBASE-17480
> Project: HBase
>  Issue Type: Sub-task
>  Components: Region Assignment
>Affects Versions: 2.0.0
>Reporter: Stephen Yuan Jiang
>Assignee: Stephen Yuan Jiang
> Fix For: 2.0.0
>
> Attachments: HBASE-17480.v1-master.patch, HBASE-17480.v2-master.patch
>
>
> HBASE-14551 moves the split region logic to the master-side. There is no need 
> to keep region_server-side split region code.  We should remove them to avoid 
> code duplication.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17480) Remove split region code from Region Server

2017-01-18 Thread Stephen Yuan Jiang (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Yuan Jiang updated HBASE-17480:
---
Attachment: HBASE-17480.v2-master.patch

> Remove split region code from Region Server
> ---
>
> Key: HBASE-17480
> URL: https://issues.apache.org/jira/browse/HBASE-17480
> Project: HBase
>  Issue Type: Sub-task
>  Components: Region Assignment
>Affects Versions: 2.0.0
>Reporter: Stephen Yuan Jiang
>Assignee: Stephen Yuan Jiang
> Fix For: 2.0.0
>
> Attachments: HBASE-17480.v1-master.patch, HBASE-17480.v2-master.patch
>
>
> HBASE-14551 moves the split region logic to the master-side. There is no need 
> to keep region_server-side split region code.  We should remove them to avoid 
> code duplication.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17289) Avoid adding a replication peer named "lock"

2017-01-18 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829377#comment-15829377
 ] 

Hudson commented on HBASE-17289:


SUCCESS: Integrated in Jenkins build HBase-1.2-JDK7 #88 (See 
[https://builds.apache.org/job/HBase-1.2-JDK7/88/])
HBASE-17289 Avoid adding a replication peer named lock (zghao: rev 
4778995c4eefa759b01fded7bf62aaa8953db5ed)
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/replication/ReplicationPeersZKImpl.java
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/client/replication/TestReplicationAdmin.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/replication/ReplicationQueuesZKImpl.java


> Avoid adding a replication peer named "lock"
> 
>
> Key: HBASE-17289
> URL: https://issues.apache.org/jira/browse/HBASE-17289
> Project: HBase
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 1.3.0, 1.4.0, 1.1.7, 0.98.23, 1.2.4
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 1.4.0, 1.3.1, 1.2.5, 1.1.9
>
> Attachments: HBASE-17289-branch-1.1.patch, 
> HBASE-17289-branch-1.2.patch, HBASE-17289-branch-1.3.patch, 
> HBASE-17289-branch-1.patch
>
>
> When zk based replication queue is used and useMulti is false, the steps of 
> transfer replication queues are first add a lock, then copy nodes, finally 
> clean old queue and the lock. And the default lock znode's name is "lock". So 
> we should avoid adding a peer named "lock". 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829366#comment-15829366
 ] 

stack commented on HBASE-17488:
---

Patch seems fine. What sort of benefit do you expect [~chia7712]? Thanks.

> WALEdit should be lazily instantiated
> -
>
> Key: HBASE-17488
> URL: https://issues.apache.org/jira/browse/HBASE-17488
> Project: HBase
>  Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Trivial
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17488.branch-1.v0.patch
>
>
> Some trivial improvement.
> # create the WALEdit on step 3 instead of step 2
> # count the cells from coprocessor
> # don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829345#comment-15829345
 ] 

Hadoop QA commented on HBASE-17488:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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} 1m 
53s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s 
{color} | {color:green} branch-1 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s 
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
58s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
17s {color} | {color:green} branch-1 passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 59s 
{color} | {color:red} hbase-server in branch-1 has 2 extant Findbugs warnings. 
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s 
{color} | {color:green} branch-1 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s 
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s 
{color} | {color:green} the patch passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 32s 
{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_80 {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} 0m 
57s {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} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
15m 27s {color} | {color:green} The 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} hbaseprotoc {color} | {color:green} 0m 
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 8s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 24s 
{color} | {color:green} the patch passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 84m 37s {color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
17s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 114m 54s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestMetaWithReplicas |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:e01ee2f |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12848217/HBASE-17488.branch-1.v0.patch
 |
| JIRA Issue | HBASE-17488 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 2c792c417ad7 3.13.0-105-generic #152-Ubuntu SMP Fri Dec 2 
15:37:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
|

[jira] [Created] (HBASE-17489) ClientScanner may send a next request to a RegionScanner which has been exhausted

2017-01-18 Thread Duo Zhang (JIRA)

Duo Zhang created HBASE-17489:
-

 Summary: ClientScanner may send a next request to a RegionScanner 
which has been exhausted
 Key: HBASE-17489
 URL: https://issues.apache.org/jira/browse/HBASE-17489
 Project: HBase
  Issue Type: Bug
  Components: Client, scan
Affects Versions: 2.0.0
Reporter: Duo Zhang
Priority: Critical
 Fix For: 2.0.0


Found it when implementing HBASE-17045. Seems the final result of the scan is 
correct but no doubt the logic is broken. We need to fix it to stop things get 
worse in the future.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17165) Add retry to LoadIncrementalHFiles tool

2017-01-18 Thread stack (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-17165:
--
Attachment: HBASE-17165.branch-1.001.patch

Retry. Don't think the unit test failures related.

> Add retry to LoadIncrementalHFiles tool
> ---
>
> Key: HBASE-17165
> URL: https://issues.apache.org/jira/browse/HBASE-17165
> Project: HBase
>  Issue Type: Improvement
>  Components: hbase, HFile, tooling
>Affects Versions: 2.0.0, 1.2.3
>Reporter: Mike Grimes
>Assignee: Mike Grimes
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17165.branch-1.001.patch, 
> HBASE-17165.branch-1.001.patch, HBASE-17165.branch-1.2.001.patch, 
> HBASE-17165.branch-1.2.002.patch, HBASE-17165.branch-1.2.003.patch, 
> HBASE-17165.branch-1.2.004.patch, HBASE-17165.master.001.patch, 
> HBASE-17165.master.002.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> As using the LoadIncrementalHFiles tool with S3 as the filesystem is prone to 
> failing due to FileNotFoundExceptions due to inconsistency, simple, 
> configurable retry logic was added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-16786) Procedure V2 - Move ZK-lock's uses to Procedure framework locks (LockProcedure)

2017-01-18 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-16786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829330#comment-15829330
 ] 

stack commented on HBASE-16786:
---

-012 fixes silly error in TestTokenAuth. TestAcidG seems a flake in this case. 
Passes locally. Fixed whitespace. Also addresses [~appy] review (+1 Appy? Or 
[~syuanjiang]?)

> Procedure V2 - Move ZK-lock's uses to Procedure framework locks 
> (LockProcedure)
> ---
>
> Key: HBASE-16786
> URL: https://issues.apache.org/jira/browse/HBASE-16786
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Appy
>Assignee: Matteo Bertozzi
> Attachments: HBASE-16786.master.001.patch, 
> HBASE-16786.master.002.patch, HBASE-16786.master.003.patch, 
> HBASE-16786.master.004.patch, HBASE-16786.master.005.patch, 
> HBASE-16786.master.006.patch, HBASE-16786.master.007.patch, 
> HBASE-16786.master.008.patch, HBASE-16786.master.009.patch, 
> HBASE-16786.master.010.patch, HBASE-16786.master.011.patch, 
> HBASE-16786.master.012.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-16786) Procedure V2 - Move ZK-lock's uses to Procedure framework locks (LockProcedure)

2017-01-18 Thread stack (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-16786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-16786:
--
Attachment: HBASE-16786.master.012.patch

> Procedure V2 - Move ZK-lock's uses to Procedure framework locks 
> (LockProcedure)
> ---
>
> Key: HBASE-16786
> URL: https://issues.apache.org/jira/browse/HBASE-16786
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Appy
>Assignee: Matteo Bertozzi
> Attachments: HBASE-16786.master.001.patch, 
> HBASE-16786.master.002.patch, HBASE-16786.master.003.patch, 
> HBASE-16786.master.004.patch, HBASE-16786.master.005.patch, 
> HBASE-16786.master.006.patch, HBASE-16786.master.007.patch, 
> HBASE-16786.master.008.patch, HBASE-16786.master.009.patch, 
> HBASE-16786.master.010.patch, HBASE-16786.master.011.patch, 
> HBASE-16786.master.012.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17484) Add non cached version of OffheapKV for write path

2017-01-18 Thread ramkrishna.s.vasudevan (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829324#comment-15829324
 ] 

ramkrishna.s.vasudevan commented on HBASE-17484:


bq.Any evidence to present to justify why we should have these new types? We've 
gone this route a bunch of times in our history adding caching and then undoing 
it. The argument is that reading these lengths by parsing offheap bytes is slow?
Previously this offheapKV was getting used only in read path and we found that 
caching it did not have a big impact because they are all short lived objects 
that gets created in case of random reads. And during a block seek caching 
these values helped us.
But in case of write path we add them to the memstore and we see that if we 
have more caching then the flush related calculations related to blocking the 
incoming write requests (due to higher limit breach) are impacted more by this 
caching. If you see the KeyValue case we don't do these caching and so we try 
to do the same here for the write path so that we have the same data and heap 
overhead for both KeyValues and OffheapKeyValues.
bq.After this patch, how many versions of KeyValue do we have?
We thought about this and this would be a question. I think after that 
ExtendedCell was added we have considerably reduced the variations. Let me 
check on that on exact number.
bq.Do we have to have a OffheapKeyValue and Cached.
With 'Cached' I meant the an OffheapKV with more of its states cached. 
ByteBufferCell for now is purely only for direct. Anything with non-direct we 
create KV out of it.
bq.OffheapKeyValue.FIXED_OVERHEAD + Bytes.SIZEOF_INT + Bytes.SIZEOF_SHORT;  
is that a double ''?
I think it is ok as we cache the keyLen (an int) and rowLen (a short) here. 


> Add non cached version of OffheapKV for write path
> --
>
> Key: HBASE-17484
> URL: https://issues.apache.org/jira/browse/HBASE-17484
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-17484.patch
>
>
> After running lot of different performance tests for various scenarios and 
> with multi threads we thought that is  better to have a version of OffheapKV 
> in write path that does not cache anything and its fixed_overhead is equal to 
> that in KeyValue. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17346) Add coprocessor service support

2017-01-18 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829317#comment-15829317
 ] 

Hadoop QA commented on HBASE-17346:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 14s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 24s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
43s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
47s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
23s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
27s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 24s 
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
37s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
26m 20s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
37s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 23s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 0s 
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 21s 
{color} | {color:green} hbase-endpoint in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
13s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 40m 48s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12848228/HBASE-17346-v1.patch |
| JIRA Issue | HBASE-17346 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux f8b476b6bca1 3.13.0-95-generic #142-Ubuntu SMP Fri Aug 12 
17:00:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / cb9ce2c |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5326/testReport/ |
| modules | C: hbase-client hbase-endpoint U: . |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5326/console |
| Powered by | Apache Yetus 0.3.0   http://yetus.apache.org |


This message was automatically generated.



> Add coprocessor service support
>

[jira] [Commented] (HBASE-17487) Potential data loss when pipeline is pushed to snapshot

2017-01-18 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829308#comment-15829308
 ] 

Hadoop QA commented on HBASE-17487:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 13s 
{color} | {color:blue} Docker mode activated. {color} |
| {color: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/0.3.0/precommit-patchnames for 
instructions. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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 
46s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
40s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
12s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
36s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 24s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
37s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 32s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
24m 43s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s 
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 80m 26s {color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
14s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 116m 16s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12848207/17487.v1.txt |
| JIRA Issue | HBASE-17487 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 089e51c5fdc1 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12 
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / cb9ce2c |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5322/artifact/patchprocess/patch-unit-hbase-server.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5322/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5322/console |
| Powered by | Apache Yetus 0.3.0   http://yetus.apache.org |


This message was automatically

[jira] [Commented] (HBASE-17045) Unify the implementation of small scan and regular scan

2017-01-18 Thread Duo Zhang (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829288#comment-15829288
 ] 

Duo Zhang commented on HBASE-17045:
---

Ping [~stack] [~enis].

> Unify the implementation of small scan and regular scan
> ---
>
> Key: HBASE-17045
> URL: https://issues.apache.org/jira/browse/HBASE-17045
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client, scan
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-17045.patch, HBASE-17045-v1.patch, 
> HBASE-17045-v2.patch, HBASE-17045-v3.patch, HBASE-17045-v4.patch, 
> HBASE-17045-v5.patch
>
>
> See [~enis]'s comment in HBASE-16838
> https://issues.apache.org/jira/browse/HBASE-16838?focusedCommentId=15637803=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15637803
> But there is another scenario that we need small scan is that, we do not know 
> the stop row but we only want a small set of results. For example, in the 
> implementation of region locator, we will use small scan and set caching to 1 
> as we only need one row.
> So I think we need to add a new option(maybe called limit?) for the scan 
> object, and deprecate the small option. And the server side modification 
> should also be committed to branch-1 to simplify the logic of async client in 
> 2.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17346) Add coprocessor service support

2017-01-18 Thread Duo Zhang (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829281#comment-15829281
 ] 

Duo Zhang commented on HBASE-17346:
---

[~stack] What's your opinion sir? Do you like the approach?

Thanks.

> Add coprocessor service support
> ---
>
> Key: HBASE-17346
> URL: https://issues.apache.org/jira/browse/HBASE-17346
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client, Coprocessors
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: 17346.suggestion.txt, HBASE-17346.patch, 
> HBASE-17346-v1.patch
>
>
> I think we need to redesign the API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17346) Add coprocessor service support

2017-01-18 Thread Duo Zhang (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang updated HBASE-17346:
--
Attachment: HBASE-17346-v1.patch

> Add coprocessor service support
> ---
>
> Key: HBASE-17346
> URL: https://issues.apache.org/jira/browse/HBASE-17346
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client, Coprocessors
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: 17346.suggestion.txt, HBASE-17346.patch, 
> HBASE-17346-v1.patch
>
>
> I think we need to redesign the API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17045) Unify the implementation of small scan and regular scan

2017-01-18 Thread Duo Zhang (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang updated HBASE-17045:
--
Attachment: HBASE-17045-v5.patch

Add a readType option for Scan to control whether we should use pread for this 
scan.

> Unify the implementation of small scan and regular scan
> ---
>
> Key: HBASE-17045
> URL: https://issues.apache.org/jira/browse/HBASE-17045
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client, scan
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-17045.patch, HBASE-17045-v1.patch, 
> HBASE-17045-v2.patch, HBASE-17045-v3.patch, HBASE-17045-v4.patch, 
> HBASE-17045-v5.patch
>
>
> See [~enis]'s comment in HBASE-16838
> https://issues.apache.org/jira/browse/HBASE-16838?focusedCommentId=15637803=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15637803
> But there is another scenario that we need small scan is that, we do not know 
> the stop row but we only want a small set of results. For example, in the 
> implementation of region locator, we will use small scan and set caching to 1 
> as we only need one row.
> So I think we need to add a new option(maybe called limit?) for the scan 
> object, and deprecate the small option. And the server side modification 
> should also be committed to branch-1 to simplify the logic of async client in 
> 2.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17289) Avoid adding a replication peer named "lock"

2017-01-18 Thread Guanghao Zhang (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guanghao Zhang updated HBASE-17289:
---
   Resolution: Fixed
Fix Version/s: 1.1.9
   1.2.5
   1.3.1
   Status: Resolved  (was: Patch Available)

> Avoid adding a replication peer named "lock"
> 
>
> Key: HBASE-17289
> URL: https://issues.apache.org/jira/browse/HBASE-17289
> Project: HBase
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 1.3.0, 1.4.0, 1.1.7, 0.98.23, 1.2.4
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 1.4.0, 1.3.1, 1.2.5, 1.1.9
>
> Attachments: HBASE-17289-branch-1.1.patch, 
> HBASE-17289-branch-1.2.patch, HBASE-17289-branch-1.3.patch, 
> HBASE-17289-branch-1.patch
>
>
> When zk based replication queue is used and useMulti is false, the steps of 
> transfer replication queues are first add a lock, then copy nodes, finally 
> clean old queue and the lock. And the default lock znode's name is "lock". So 
> we should avoid adding a peer named "lock". 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread ChiaPing Tsai (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ChiaPing Tsai updated HBASE-17488:
--
Assignee: ChiaPing Tsai
  Status: Patch Available  (was: Open)

> WALEdit should be lazily instantiated
> -
>
> Key: HBASE-17488
> URL: https://issues.apache.org/jira/browse/HBASE-17488
> Project: HBase
>  Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Trivial
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17488.branch-1.v0.patch
>
>
> Some trivial improvement.
> # create the WALEdit on step 3 instead of step 2
> # count the cells from coprocessor
> # don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread ChiaPing Tsai (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ChiaPing Tsai updated HBASE-17488:
--
Attachment: HBASE-17488.branch-1.v0.patch

> WALEdit should be lazily instantiated
> -
>
> Key: HBASE-17488
> URL: https://issues.apache.org/jira/browse/HBASE-17488
> Project: HBase
>  Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Priority: Trivial
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17488.branch-1.v0.patch
>
>
> Some trivial improvement.
> # create the WALEdit on step 3 instead of step 2
> # count the cells from coprocessor
> # don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread ChiaPing Tsai (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ChiaPing Tsai updated HBASE-17488:
--
Attachment: HBASE-17488.v0.patch

> WALEdit should be lazily instantiated
> -
>
> Key: HBASE-17488
> URL: https://issues.apache.org/jira/browse/HBASE-17488
> Project: HBase
>  Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Priority: Trivial
> Fix For: 2.0.0, 1.4.0
>
>
> Some trivial improvement.
> # create the WALEdit on step 3 instead of step 2
> # count the cells from coprocessor
> # don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread ChiaPing Tsai (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ChiaPing Tsai updated HBASE-17488:
--
Attachment: (was: HBASE-17488.v0.patch)

> WALEdit should be lazily instantiated
> -
>
> Key: HBASE-17488
> URL: https://issues.apache.org/jira/browse/HBASE-17488
> Project: HBase
>  Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Priority: Trivial
> Fix For: 2.0.0, 1.4.0
>
>
> Some trivial improvement.
> # create the WALEdit on step 3 instead of step 2
> # count the cells from coprocessor
> # don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17486) Tighten the contract for batch client methods

2017-01-18 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829244#comment-15829244
 ] 

Hudson commented on HBASE-17486:


SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2344 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/2344/])
HBASE-17486 Tighten the contract for batch client methods (Michael (stack: rev 
8f1d0a2b84e4f4dc96406b4748998c7d6eeacbd3)
* (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Table.java


> Tighten the contract for batch client methods
> -
>
> Key: HBASE-17486
> URL: https://issues.apache.org/jira/browse/HBASE-17486
> Project: HBase
>  Issue Type: Bug
>  Components: API
>Reporter: Michael Axiak
>Assignee: Michael Axiak
>Priority: Trivial
>  Labels: documentation
> Fix For: 2.0.0
>
> Attachments: HBASE-17486.patch
>
>
> Right now, the API documentation for Table#get(List) and Table#batch(List, 
> Result[]) both leave open the possibility for the ordering of the result 
> array to be independent of the input actions.
> In at least the batch method case, ordering of the result array is important 
> in order to know which partial requests failed in the event of an exception. 
> Since that contact is required in the batch case, I think it should be 
> extended to the get(List) case as well to make the API easier.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread ChiaPing Tsai (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ChiaPing Tsai updated HBASE-17488:
--
Fix Version/s: (was: 1.3.0)
   1.4.0

> WALEdit should be lazily instantiated
> -
>
> Key: HBASE-17488
> URL: https://issues.apache.org/jira/browse/HBASE-17488
> Project: HBase
>  Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Priority: Trivial
> Fix For: 2.0.0, 1.4.0
>
>
> Some trivial improvement.
> # create the WALEdit on step 3 instead of step 2
> # count the cells from coprocessor
> # don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread ChiaPing Tsai (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ChiaPing Tsai updated HBASE-17488:
--
Fix Version/s: (was: 1.4.0)
   1.3.0

> WALEdit should be lazily instantiated
> -
>
> Key: HBASE-17488
> URL: https://issues.apache.org/jira/browse/HBASE-17488
> Project: HBase
>  Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Priority: Trivial
> Fix For: 2.0.0, 1.3.0
>
>
> Some trivial improvement.
> # create the WALEdit on step 3 instead of step 2
> # count the cells from coprocessor
> # don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread ChiaPing Tsai (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ChiaPing Tsai updated HBASE-17488:
--
Fix Version/s: 1.4.0
   2.0.0

> WALEdit should be lazily instantiated
> -
>
> Key: HBASE-17488
> URL: https://issues.apache.org/jira/browse/HBASE-17488
> Project: HBase
>  Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Priority: Trivial
> Fix For: 2.0.0, 1.3.0
>
>
> Some trivial improvement.
> # create the WALEdit on step 3 instead of step 2
> # count the cells from coprocessor
> # don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-17488) WALEdit should be lazily instantiated

2017-01-18 Thread ChiaPing Tsai (JIRA)

ChiaPing Tsai created HBASE-17488:
-

 Summary: WALEdit should be lazily instantiated
 Key: HBASE-17488
 URL: https://issues.apache.org/jira/browse/HBASE-17488
 Project: HBase
  Issue Type: Improvement
Reporter: ChiaPing Tsai
Priority: Trivial


Some trivial improvement.
# create the WALEdit on step 3 instead of step 2
# count the cells from coprocessor
# don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0

2017-01-18 Thread Ted Yu (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-16179:
---
Attachment: 16179.v22.txt

Patch v22 fixes white space.

> Fix compilation errors when building hbase-spark against Spark 2.0
> --
>
> Key: HBASE-16179
> URL: https://issues.apache.org/jira/browse/HBASE-16179
> Project: HBase
>  Issue Type: Bug
>  Components: spark
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: 16179.v0.txt, 16179.v10.txt, 16179.v11.txt, 
> 16179.v12.txt, 16179.v12.txt, 16179.v12.txt, 16179.v13.txt, 16179.v15.txt, 
> 16179.v16.txt, 16179.v18.txt, 16179.v19.txt, 16179.v19.txt, 16179.v1.txt, 
> 16179.v1.txt, 16179.v20.txt, 16179.v22.txt, 16179.v4.txt, 16179.v5.txt, 
> 16179.v7.txt, 16179.v8.txt, 16179.v9.txt
>
>
> I tried building hbase-spark module against Spark-2.0 snapshot and got the 
> following compilation errors:
> http://pastebin.com/bg3w247a
> Some Spark classes such as DataTypeParser and Logging are no longer 
> accessible to downstream projects.
> hbase-spark module should not depend on such classes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0

2017-01-18 Thread Ted Yu (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829240#comment-15829240
 ] 

Ted Yu commented on HBASE-16179:


When I followed suggestion for "no valid targets" scaladoc warning, I got:
{code}
[ERROR] 
/Users/tyu/trunk/hbase-spark/src/main/scala/org/apache/hadoop/hbase/spark/HBaseContext.scala:62:
 error: not found: type param
[ERROR] class HBaseContext(@(transient @param) sc: SparkContext,
[ERROR]
{code}

> Fix compilation errors when building hbase-spark against Spark 2.0
> --
>
> Key: HBASE-16179
> URL: https://issues.apache.org/jira/browse/HBASE-16179
> Project: HBase
>  Issue Type: Bug
>  Components: spark
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: 16179.v0.txt, 16179.v10.txt, 16179.v11.txt, 
> 16179.v12.txt, 16179.v12.txt, 16179.v12.txt, 16179.v13.txt, 16179.v15.txt, 
> 16179.v16.txt, 16179.v18.txt, 16179.v19.txt, 16179.v19.txt, 16179.v1.txt, 
> 16179.v1.txt, 16179.v20.txt, 16179.v4.txt, 16179.v5.txt, 16179.v7.txt, 
> 16179.v8.txt, 16179.v9.txt
>
>
> I tried building hbase-spark module against Spark-2.0 snapshot and got the 
> following compilation errors:
> http://pastebin.com/bg3w247a
> Some Spark classes such as DataTypeParser and Logging are no longer 
> accessible to downstream projects.
> hbase-spark module should not depend on such classes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0

2017-01-18 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829226#comment-15829226
 ] 

Hadoop QA commented on HBASE-16179:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 11s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m 2s 
{color} | {color:blue} The patch file was not named according to hbase's naming 
conventions. Please see 
https://yetus.apache.org/documentation/0.3.0/precommit-patchnames for 
instructions. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 9 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 18s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 
52s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 41s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
33s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m 
40s {color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s 
{color} | {color:blue} Skipped patched modules with no Java source: 
hbase-assembly . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 
36s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 16s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 1m 
26s {color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 15s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 10m 
0s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m 39s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 9m 39s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} scalac {color} | {color:green} 9m 39s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 
4s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 3m 
18s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s 
{color} | {color:red} The patch 6 line(s) with tabs. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 12s 
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
48m 33s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s 
{color} | {color:blue} Skipped patched modules with no Java source: 
hbase-spark2.0-compat hbase-spark1.6-compat . hbase-assembly hbase-spark-1.6 
hbase-spark-1.6-scala-2.10 hbase-spark-scala-2.10 
hbase-spark1.6-compat-scala-2.10 hbase-spark2.0-compat-scala-2.10 {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 
44s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 2m 33s 
{color} | {color:red} root generated 55 new + 18 unchanged - 1 fixed = 73 total 
(was 19) {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 11s 
{color} | {color:red} hbase-spark generated 1 new + 17 unchanged - 1 fixed = 18 
total (was 18) {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 10s 
{color} | {color:red} hbase-spark-1.6 generated 18 new + 0 unchanged - 0 fixed 
= 18 total (was 0) {color} |
| {color:red}-1{color} | {color:red} javadoc {color} |

[jira] [Updated] (HBASE-17487) Potential data loss when pipeline is pushed to snapshot

2017-01-18 Thread Ted Yu (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-17487:
---
Status: Patch Available  (was: Open)

> Potential data loss when pipeline is pushed to snapshot
> ---
>
> Key: HBASE-17487
> URL: https://issues.apache.org/jira/browse/HBASE-17487
> Project: HBase
>  Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 17487.v1.txt
>
>
> In CompactingMemStore#pushPipelineToSnapshot() , there is limit of 3 
> iterations of pipeline.swap() call after which an empty ImmutableSegment is 
> used as snapshot.
> However, after 3rd iteration, the return value from swap() is not checked.
> If the 3rd swap() call is successful, the versioned list would be swapped 
> with null in pipeline and snapshot being overwritten with the empty 
> ImmutableSegment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17487) Potential data loss when pipeline is pushed to snapshot

2017-01-18 Thread Ted Yu (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-17487:
---
Attachment: 17487.v1.txt

[~anastas]:
Mind taking a look at the patch ?

> Potential data loss when pipeline is pushed to snapshot
> ---
>
> Key: HBASE-17487
> URL: https://issues.apache.org/jira/browse/HBASE-17487
> Project: HBase
>  Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 17487.v1.txt
>
>
> In CompactingMemStore#pushPipelineToSnapshot() , there is limit of 3 
> iterations of pipeline.swap() call after which an empty ImmutableSegment is 
> used as snapshot.
> However, after 3rd iteration, the return value from swap() is not checked.
> If the 3rd swap() call is successful, the versioned list would be swapped 
> with null in pipeline and snapshot being overwritten with the empty 
> ImmutableSegment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-17487) Potential data loss when pipeline is pushed to snapshot

2017-01-18 Thread Ted Yu (JIRA)

Ted Yu created HBASE-17487:
--

 Summary: Potential data loss when pipeline is pushed to snapshot
 Key: HBASE-17487
 URL: https://issues.apache.org/jira/browse/HBASE-17487
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu


In CompactingMemStore#pushPipelineToSnapshot() , there is limit of 3 iterations 
of pipeline.swap() call after which an empty ImmutableSegment is used as 
snapshot.

However, after 3rd iteration, the return value from swap() is not checked.
If the 3rd swap() call is successful, the versioned list would be swapped with 
null in pipeline and snapshot being overwritten with the empty ImmutableSegment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17396) Add first async admin impl and implement balance methods

2017-01-18 Thread Guanghao Zhang (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guanghao Zhang updated HBASE-17396:
---
  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

> Add first async admin impl and implement balance methods
> 
>
> Key: HBASE-17396
> URL: https://issues.apache.org/jira/browse/HBASE-17396
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-17396-v1.patch, HBASE-17396-v2.patch, 
> HBASE-17396-v3.patch, HBASE-17396-v4.patch, HBASE-17396-v5.patch, 
> HBASE-17396-v6.patch, HBASE-17396-v7.patch, HBASE-17396-v8.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17396) Add first async admin impl and implement balance methods

2017-01-18 Thread Guanghao Zhang (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829177#comment-15829177
 ] 

Guanghao Zhang commented on HBASE-17396:


Pushed to master. And thanks [~Apache9] for review.

> Add first async admin impl and implement balance methods
> 
>
> Key: HBASE-17396
> URL: https://issues.apache.org/jira/browse/HBASE-17396
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-17396-v1.patch, HBASE-17396-v2.patch, 
> HBASE-17396-v3.patch, HBASE-17396-v4.patch, HBASE-17396-v5.patch, 
> HBASE-17396-v6.patch, HBASE-17396-v7.patch, HBASE-17396-v8.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17407) Correct update of maxFlushedSeqId in HRegion

2017-01-18 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829136#comment-15829136
 ] 

Hadoop QA commented on HBASE-17407:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} 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 
27s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
45s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
48s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
45s {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 {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} checkstyle {color} | {color:green} 0m 
45s {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} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
27m 27s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
59s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s 
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 103m 58s 
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
16s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 144m 28s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests | 
org.apache.hadoop.hbase.regionserver.wal.TestLogRolling |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.6 Server=1.12.6 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12848163/HBASE-17407-V02.patch 
|
| JIRA Issue | HBASE-17407 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux bb96e65f8743 3.13.0-100-generic #147-Ubuntu SMP Tue Oct 18 
16:48:51 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / 8f1d0a2 |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5320/artifact/patchprocess/patch-unit-hbase-server.txt
 |
| unit test logs |  
https://builds.apache.org/job/PreCommit-HBASE-Build/5320/artifact/patchprocess/patch-unit-hbase-server.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5320/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5320/console |
| Powered by | Apache Yetus 0.3.0   http://yetus.apache.org |


This message was automatically generated.



>

[jira] [Commented] (HBASE-17165) Add retry to LoadIncrementalHFiles tool

2017-01-18 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829131#comment-15829131
 ] 

Hadoop QA commented on HBASE-17165:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 19m 32s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 8m 
28s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 54s 
{color} | {color:green} branch-1 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 53s 
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 
14s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
28s {color} | {color:green} branch-1 passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 23s 
{color} | {color:red} hbase-server in branch-1 has 2 extant Findbugs warnings. 
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 47s 
{color} | {color:green} branch-1 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s 
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
2s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 53s 
{color} | {color:green} the patch passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 53s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 54s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 54s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 
8s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
21s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
23m 10s {color} | {color:green} The 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} hbaseprotoc {color} | {color:green} 0m 
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 
36s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 41s 
{color} | {color:green} the patch passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 145m 11s 
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
40s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 214m 5s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestSnapshotCloneIndependence |
|   | hadoop.hbase.client.TestMetaWithReplicas |
|   | hadoop.hbase.master.TestMasterBalanceThrottling |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:e01ee2f |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12848147/HBASE-17165.branch-1.001.patch
 |
| JIRA Issue | HBASE-17165 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux e45da0731edc 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28 
20:42:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool |

[jira] [Commented] (HBASE-17475) Stack overflow in AsyncProcess if retry too much

2017-01-18 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829033#comment-15829033
 ] 

Hudson commented on HBASE-17475:


FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #83 (See 
[https://builds.apache.org/job/HBase-1.3-JDK7/83/])
HBASE-17475 Stack overflow in AsyncProcess if retry too much (Allan (tedyu: rev 
f840bd196fd696621d61c75875f5d2d1d996dd0f)
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncProcess.java


> Stack overflow in AsyncProcess if retry too much
> 
>
> Key: HBASE-17475
> URL: https://issues.apache.org/jira/browse/HBASE-17475
> Project: HBase
>  Issue Type: Bug
>  Components: API, Client
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Allan Yang
>Assignee: Allan Yang
>  Labels: trivial
> Fix For: 2.0.0, 1.4.0, 1.3.1
>
> Attachments: HBASE-17475-branch-1.patch, 
> HBASE-17475-branch-1.v2.patch, HBASE-17475-branch-1.v3.patch, 
> HBASE-17475.patch, HBASE-17475.v2.patch
>
>
> In AsyncProcess, we resubmit the retry task in the same thread
> {code}
>   // run all the runnables
>   for (Runnable runnable : runnables) {
> if ((--actionsRemaining == 0) && reuseThread) {
>   runnable.run();
> } else {
>   try {
> pool.submit(runnable);
>   } 
>   ..
> {code}
> But, if we retry too much time. soon, stack overflow will occur. This is very 
> common in clusters with Phoenix. Phoenix need to write index table in the 
> normal write path, retry will cause stack overflow exception.
> {noformat}
> "htable-pool19-t2" #582 daemon prio=5 os_prio=0 tid=0x02687800 
> nid=0x4a96 waiting on condition [0x7fe3f6301000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
>   at java.lang.Thread.sleep(Native Method)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.resubmit(AsyncProcess.java:1174)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.receiveMultiAction(AsyncProcess.java:1321)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.access$1200(AsyncProcess.java:575)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl$SingleServerRequestRunnable.run(AsyncProcess.java:729)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.sendMultiAction(AsyncProcess.java:977)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.groupAndSendMultiAction(AsyncProcess.java:886)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.resubmit(AsyncProcess.java:1181)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.receiveMultiAction(AsyncProcess.java:1321)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.access$1200(AsyncProcess.java:575)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl$SingleServerRequestRunnable.run(AsyncProcess.java:729)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.sendMultiAction(AsyncProcess.java:977)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.groupAndSendMultiAction(AsyncProcess.java:886)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.resubmit(AsyncProcess.java:1181)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.receiveMultiAction(AsyncProcess.java:1321)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.access$1200(AsyncProcess.java:575)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl$SingleServerRequestRunnable.run(AsyncProcess.java:729)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.sendMultiAction(AsyncProcess.java:977)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.groupAndSendMultiAction(AsyncProcess.java:886)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.resubmit(AsyncProcess.java:1181)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.receiveMultiAction(AsyncProcess.java:1321)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.access$1200(AsyncProcess.java:575)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl$SingleServerRequestRunnable.run(AsyncProcess.java:729)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.sendMultiAction(AsyncProcess.java:977)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.groupAndSendMultiAction(AsyncProcess.java:886)
>   at 
>

[jira] [Commented] (HBASE-16786) Procedure V2 - Move ZK-lock's uses to Procedure framework locks (LockProcedure)

2017-01-18 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-16786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828999#comment-15828999
 ] 

Hadoop QA commented on HBASE-16786:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 10s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 15 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 8s 
{color} | {color:blue} Maven dependency ordering for branch {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} 0m 55s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
25s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
29s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 
24s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 49s 
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 9s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
3s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 55s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 55s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
27s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
33s {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 1 line(s) that end in whitespace. Use git 
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
24m 54s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 
41s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 45s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 24s 
{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 63m 21s {color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 29s 
{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
32s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 107m 1s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.security.token.TestTokenAuthentication |
| Timed out junit tests | org.apache.hadoop.hbase.TestAcidGuarantees |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12848137/HBASE-16786.master.011.patch
 |
| JIRA Issue | HBASE-16786 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 6b4523660a53 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12 
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / 6cbc375 |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| whitespace |

[jira] [Updated] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0

2017-01-18 Thread Ted Yu (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-16179:
---
Attachment: 16179.v20.txt

Patch v20 removes the secondPartTestsExecution in pom.xml files.

Added one paragraph spark.adoc for hbase-spark artifacts.

Whitespace output is no longer accessible.
Re-attaching to get the output.

> Fix compilation errors when building hbase-spark against Spark 2.0
> --
>
> Key: HBASE-16179
> URL: https://issues.apache.org/jira/browse/HBASE-16179
> Project: HBase
>  Issue Type: Bug
>  Components: spark
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: 16179.v0.txt, 16179.v10.txt, 16179.v11.txt, 
> 16179.v12.txt, 16179.v12.txt, 16179.v12.txt, 16179.v13.txt, 16179.v15.txt, 
> 16179.v16.txt, 16179.v18.txt, 16179.v19.txt, 16179.v19.txt, 16179.v1.txt, 
> 16179.v1.txt, 16179.v20.txt, 16179.v4.txt, 16179.v5.txt, 16179.v7.txt, 
> 16179.v8.txt, 16179.v9.txt
>
>
> I tried building hbase-spark module against Spark-2.0 snapshot and got the 
> following compilation errors:
> http://pastebin.com/bg3w247a
> Some Spark classes such as DataTypeParser and Logging are no longer 
> accessible to downstream projects.
> hbase-spark module should not depend on such classes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0

2017-01-18 Thread Ted Yu (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828981#comment-15828981
 ] 

Ted Yu commented on HBASE-16179:


I looked at hbase-archetypes module where hbase-shaded-client-project and 
hbase-client-project have independent HelloHBase.java
{code}
[INFO] Apache HBase - Archetypes .. SUCCESS [  0.026 s]
[INFO] Apache HBase - Exemplar for hbase-client archetype . SUCCESS [  3.400 s]
[INFO] Apache HBase - Exemplar for hbase-shaded-client archetype SUCCESS [  
3.202 s]
[INFO] Apache HBase - Archetype builder ... SUCCESS [ 10.649 s]
{code}
Under hbase-archetypes/target, there is no jar produced.

For hbase-spark artifacts, I prefer the current formation.

> Fix compilation errors when building hbase-spark against Spark 2.0
> --
>
> Key: HBASE-16179
> URL: https://issues.apache.org/jira/browse/HBASE-16179
> Project: HBase
>  Issue Type: Bug
>  Components: spark
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: 16179.v0.txt, 16179.v10.txt, 16179.v11.txt, 
> 16179.v12.txt, 16179.v12.txt, 16179.v12.txt, 16179.v13.txt, 16179.v15.txt, 
> 16179.v16.txt, 16179.v18.txt, 16179.v19.txt, 16179.v19.txt, 16179.v1.txt, 
> 16179.v1.txt, 16179.v4.txt, 16179.v5.txt, 16179.v7.txt, 16179.v8.txt, 
> 16179.v9.txt
>
>
> I tried building hbase-spark module against Spark-2.0 snapshot and got the 
> following compilation errors:
> http://pastebin.com/bg3w247a
> Some Spark classes such as DataTypeParser and Logging are no longer 
> accessible to downstream projects.
> hbase-spark module should not depend on such classes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0

2017-01-18 Thread Ted Yu (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828965#comment-15828965
 ] 

Ted Yu commented on HBASE-16179:


After dropping spark-2.0 profile, I got:
{code}
[INFO] Compiling 51 source files to 
/hbase/hbase-spark-scala-2.10/target/classes at 1484781776334
...
[WARNING] 
/hbase/hbase-spark/src/main/scala/org/apache/hadoop/hbase/spark/DefaultSource.scala:26:
 warning: imported `Logging' is permanently hidden by definition of object 
Logging in package spark
[WARNING] import org.apache.hadoop.hbase.spark.Logging
[WARNING]  ^
[ERROR] 
/hbase/hbase-spark/src/main/scala/org/apache/spark/sql/datasources/hbase/HBaseTableCatalog.scala:79:
 error: not found: value DataTypeParserWrapper
[ERROR] sType.map(DataTypeParserWrapper.parse(_)).getOrElse{
[ERROR]   ^
{code}

> Fix compilation errors when building hbase-spark against Spark 2.0
> --
>
> Key: HBASE-16179
> URL: https://issues.apache.org/jira/browse/HBASE-16179
> Project: HBase
>  Issue Type: Bug
>  Components: spark
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: 16179.v0.txt, 16179.v10.txt, 16179.v11.txt, 
> 16179.v12.txt, 16179.v12.txt, 16179.v12.txt, 16179.v13.txt, 16179.v15.txt, 
> 16179.v16.txt, 16179.v18.txt, 16179.v19.txt, 16179.v19.txt, 16179.v1.txt, 
> 16179.v1.txt, 16179.v4.txt, 16179.v5.txt, 16179.v7.txt, 16179.v8.txt, 
> 16179.v9.txt
>
>
> I tried building hbase-spark module against Spark-2.0 snapshot and got the 
> following compilation errors:
> http://pastebin.com/bg3w247a
> Some Spark classes such as DataTypeParser and Logging are no longer 
> accessible to downstream projects.
> hbase-spark module should not depend on such classes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17486) Tighten the contract for batch client methods

2017-01-18 Thread Michael Axiak (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828960#comment-15828960
 ] 

Michael Axiak commented on HBASE-17486:
---

Thanks for the quick resolution!

> Tighten the contract for batch client methods
> -
>
> Key: HBASE-17486
> URL: https://issues.apache.org/jira/browse/HBASE-17486
> Project: HBase
>  Issue Type: Bug
>  Components: API
>Reporter: Michael Axiak
>Assignee: Michael Axiak
>Priority: Trivial
>  Labels: documentation
> Fix For: 2.0.0
>
> Attachments: HBASE-17486.patch
>
>
> Right now, the API documentation for Table#get(List) and Table#batch(List, 
> Result[]) both leave open the possibility for the ordering of the result 
> array to be independent of the input actions.
> In at least the batch method case, ordering of the result array is important 
> in order to know which partial requests failed in the event of an exception. 
> Since that contact is required in the batch case, I think it should be 
> extended to the get(List) case as well to make the API easier.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17486) Tighten the contract for batch client methods

2017-01-18 Thread stack (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-17486:
--
Assignee: Michael Axiak

> Tighten the contract for batch client methods
> -
>
> Key: HBASE-17486
> URL: https://issues.apache.org/jira/browse/HBASE-17486
> Project: HBase
>  Issue Type: Bug
>  Components: API
>Reporter: Michael Axiak
>Assignee: Michael Axiak
>Priority: Trivial
>  Labels: documentation
> Fix For: 2.0.0
>
> Attachments: HBASE-17486.patch
>
>
> Right now, the API documentation for Table#get(List) and Table#batch(List, 
> Result[]) both leave open the possibility for the ordering of the result 
> array to be independent of the input actions.
> In at least the batch method case, ordering of the result array is important 
> in order to know which partial requests failed in the event of an exception. 
> Since that contact is required in the batch case, I think it should be 
> extended to the get(List) case as well to make the API easier.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17486) Tighten the contract for batch client methods

2017-01-18 Thread stack (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-17486:
--
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: (was: 2.1.0)
   Status: Resolved  (was: Patch Available)

Pushed to master branch. Thanks for the patch [~axiak]

> Tighten the contract for batch client methods
> -
>
> Key: HBASE-17486
> URL: https://issues.apache.org/jira/browse/HBASE-17486
> Project: HBase
>  Issue Type: Bug
>  Components: API
>Reporter: Michael Axiak
>Priority: Trivial
>  Labels: documentation
> Fix For: 2.0.0
>
> Attachments: HBASE-17486.patch
>
>
> Right now, the API documentation for Table#get(List) and Table#batch(List, 
> Result[]) both leave open the possibility for the ordering of the result 
> array to be independent of the input actions.
> In at least the batch method case, ordering of the result array is important 
> in order to know which partial requests failed in the event of an exception. 
> Since that contact is required in the batch case, I think it should be 
> extended to the get(List) case as well to make the API easier.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17407) Correct update of maxFlushedSeqId in HRegion

2017-01-18 Thread Eshcar Hillel (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eshcar Hillel updated HBASE-17407:
--
Attachment: HBASE-17407-V02.patch
HBASE-17407-V01.patch

> Correct update of maxFlushedSeqId in HRegion
> 
>
> Key: HBASE-17407
> URL: https://issues.apache.org/jira/browse/HBASE-17407
> Project: HBase
>  Issue Type: Bug
>Reporter: Eshcar Hillel
> Attachments: HBASE-17407-V01.patch, HBASE-17407-V01.patch, 
> HBASE-17407-V02.patch
>
>
> The attribute maxFlushedSeqId in HRegion is used to track the max sequence id 
> in the store files and is reported to HMaster. When flushing only part of the 
> memstore content this value might be incorrect and may cause data loss.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17486) Tighten the contract for batch client methods

2017-01-18 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828946#comment-15828946
 ] 

Hadoop QA commented on HBASE-17486:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 11s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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 
52s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 17s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
9s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 17s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
19s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 17s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 17s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
22s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
9s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
26m 25s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 
53s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 16s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 0s 
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
6s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 35m 2s {color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12848148/HBASE-17486.patch |
| JIRA Issue | HBASE-17486 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux ac3d41765e4e 3.13.0-105-generic #152-Ubuntu SMP Fri Dec 2 
15:37:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / 6cbc375 |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5319/testReport/ |
| modules | C: hbase-client U: hbase-client |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5319/console |
| Powered by | Apache Yetus 0.3.0   http://yetus.apache.org |


This message was automatically generated.



> Tighten the contract for batch client methods
> -
>
> Key: HBASE-17486
> URL: https://issues.apache.org/jira/browse/HBASE-17486
> Project: HBase
>  Issue Type: Bug
>  Components: API
>Reporter: Michael Axiak
>Priority: Trivial
>

[jira] [Commented] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0

2017-01-18 Thread Sean Busbey (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828942#comment-15828942
 ] 

Sean Busbey commented on HBASE-16179:
-

{quote}
bq. could we organize them under a single parent module for hbase-spark ?
Do you have suggestion how this can be done ?
The new modules are mostly for generating artifacts for Spark 1.6 / 2.0 X Scala 
2.10 / 2.11 combinations.
{quote}

Sure, just like the top level module is a reactor with modules listed, you can 
make one of the modules it contains a reactor.

Check out the {{hbase-archetypes}} module as an example of this nesting.

> Fix compilation errors when building hbase-spark against Spark 2.0
> --
>
> Key: HBASE-16179
> URL: https://issues.apache.org/jira/browse/HBASE-16179
> Project: HBase
>  Issue Type: Bug
>  Components: spark
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: 16179.v0.txt, 16179.v10.txt, 16179.v11.txt, 
> 16179.v12.txt, 16179.v12.txt, 16179.v12.txt, 16179.v13.txt, 16179.v15.txt, 
> 16179.v16.txt, 16179.v18.txt, 16179.v19.txt, 16179.v19.txt, 16179.v1.txt, 
> 16179.v1.txt, 16179.v4.txt, 16179.v5.txt, 16179.v7.txt, 16179.v8.txt, 
> 16179.v9.txt
>
>
> I tried building hbase-spark module against Spark-2.0 snapshot and got the 
> following compilation errors:
> http://pastebin.com/bg3w247a
> Some Spark classes such as DataTypeParser and Logging are no longer 
> accessible to downstream projects.
> hbase-spark module should not depend on such classes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17349) Add doc for regionserver group-based assignment

2017-01-18 Thread Francis Liu (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828934#comment-15828934
 ] 

Francis Liu commented on HBASE-17349:
-

This was my bad. Let me know if you'd like me to write this up and you proof 
read or the vice versa? 

> Add doc for regionserver group-based assignment
> ---
>
> Key: HBASE-17349
> URL: https://issues.apache.org/jira/browse/HBASE-17349
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: stack
>Priority: Critical
> Fix For: 2.0.0
>
>
> Currently, this feature has no doc. I tried to use it last night and it took 
> reading unit tests to figure how to get it going and how to use it. I added a 
> bit to the release notes in the parent.
> Marking as a critical on 2.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0

2017-01-18 Thread Ted Yu (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828912#comment-15828912
 ] 

Ted Yu commented on HBASE-16179:


bq. could we organize them under a single parent module for hbase-spark ?

Do you have suggestion how this can be done ?
The new modules are mostly for generating artifacts for Spark 1.6 / 2.0 X Scala 
2.10 / 2.11 combinations.

bq. Where in the assembly do the generated artifacts show up?

The generated artifacts would show up under respective module.

> Fix compilation errors when building hbase-spark against Spark 2.0
> --
>
> Key: HBASE-16179
> URL: https://issues.apache.org/jira/browse/HBASE-16179
> Project: HBase
>  Issue Type: Bug
>  Components: spark
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: 16179.v0.txt, 16179.v10.txt, 16179.v11.txt, 
> 16179.v12.txt, 16179.v12.txt, 16179.v12.txt, 16179.v13.txt, 16179.v15.txt, 
> 16179.v16.txt, 16179.v18.txt, 16179.v19.txt, 16179.v19.txt, 16179.v1.txt, 
> 16179.v1.txt, 16179.v4.txt, 16179.v5.txt, 16179.v7.txt, 16179.v8.txt, 
> 16179.v9.txt
>
>
> I tried building hbase-spark module against Spark-2.0 snapshot and got the 
> following compilation errors:
> http://pastebin.com/bg3w247a
> Some Spark classes such as DataTypeParser and Logging are no longer 
> accessible to downstream projects.
> hbase-spark module should not depend on such classes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0

2017-01-18 Thread Sean Busbey (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828901#comment-15828901
 ] 

Sean Busbey commented on HBASE-16179:
-

* please things flagged by the qabot (e.g. whitespace issues)
* we're adding ~7 modules here. could we organize them under a single parent 
module for hbase-spark?
* We shouldn't have pom entries like this, because they have led to us 
mistakenly skipping tests before:
{code}
+
+maven-surefire-plugin
+
+
+
+secondPartTestsExecution
+test
+
+test
+
+
+true
+
+
+
+
{code}
* Please add docs to the ref guide explaining how to make use of these 
artifacts in a downstream project
* Could you add comments explaining the use of this profile? I thought we were 
building all spark x scala versions (and are AFAICT)?
{code}
diff --git a/hbase-spark/pom.xml b/hbase-spark/pom.xml
index 035dfcc..e195b9c 100644
--- a/hbase-spark/pom.xml
+++ b/hbase-spark/pom.xml
@@ -686,6 +685,24 @@
 
 
 
+
+  spark-2.0
+  
+
+!spark.profile
+
+  
+  
+2.0.2
+  
+  
+
+org.apache.hbase
+hbase-spark2.0-compat
+${project.version}
+
+  
+
{code}
* Where in the assembly do the generated artifacts show up?

> Fix compilation errors when building hbase-spark against Spark 2.0
> --
>
> Key: HBASE-16179
> URL: https://issues.apache.org/jira/browse/HBASE-16179
> Project: HBase
>  Issue Type: Bug
>  Components: spark
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: 16179.v0.txt, 16179.v10.txt, 16179.v11.txt, 
> 16179.v12.txt, 16179.v12.txt, 16179.v12.txt, 16179.v13.txt, 16179.v15.txt, 
> 16179.v16.txt, 16179.v18.txt, 16179.v19.txt, 16179.v19.txt, 16179.v1.txt, 
> 16179.v1.txt, 16179.v4.txt, 16179.v5.txt, 16179.v7.txt, 16179.v8.txt, 
> 16179.v9.txt
>
>
> I tried building hbase-spark module against Spark-2.0 snapshot and got the 
> following compilation errors:
> http://pastebin.com/bg3w247a
> Some Spark classes such as DataTypeParser and Logging are no longer 
> accessible to downstream projects.
> hbase-spark module should not depend on such classes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0

2017-01-18 Thread Sean Busbey (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828901#comment-15828901
 ] 

Sean Busbey edited comment on HBASE-16179 at 1/18/17 10:41 PM:
---

* please fix things flagged by the qabot (e.g. whitespace issues)
* we're adding ~7 modules here. could we organize them under a single parent 
module for hbase-spark?
* We shouldn't have pom entries like this, because they have led to us 
mistakenly skipping tests before:
{code}
+
+maven-surefire-plugin
+
+
+
+secondPartTestsExecution
+test
+
+test
+
+
+true
+
+
+
+
{code}
* Please add docs to the ref guide explaining how to make use of these 
artifacts in a downstream project
* Could you add comments explaining the use of this profile? I thought we were 
building all spark x scala versions (and are AFAICT)?
{code}
diff --git a/hbase-spark/pom.xml b/hbase-spark/pom.xml
index 035dfcc..e195b9c 100644
--- a/hbase-spark/pom.xml
+++ b/hbase-spark/pom.xml
@@ -686,6 +685,24 @@
 
 
 
+
+  spark-2.0
+  
+
+!spark.profile
+
+  
+  
+2.0.2
+  
+  
+
+org.apache.hbase
+hbase-spark2.0-compat
+${project.version}
+
+  
+
{code}
* Where in the assembly do the generated artifacts show up?


was (Author: busbey):
* please things flagged by the qabot (e.g. whitespace issues)
* we're adding ~7 modules here. could we organize them under a single parent 
module for hbase-spark?
* We shouldn't have pom entries like this, because they have led to us 
mistakenly skipping tests before:
{code}
+
+maven-surefire-plugin
+
+
+
+secondPartTestsExecution
+test
+
+test
+
+
+true
+
+
+
+
{code}
* Please add docs to the ref guide explaining how to make use of these 
artifacts in a downstream project
* Could you add comments explaining the use of this profile? I thought we were 
building all spark x scala versions (and are AFAICT)?
{code}
diff --git a/hbase-spark/pom.xml b/hbase-spark/pom.xml
index 035dfcc..e195b9c 100644
--- a/hbase-spark/pom.xml
+++ b/hbase-spark/pom.xml
@@ -686,6 +685,24 @@
 
 
 
+
+  spark-2.0
+  
+
+!spark.profile
+
+  
+  
+2.0.2
+  
+  
+
+org.apache.hbase
+hbase-spark2.0-compat
+${project.version}
+
+  
+
{code}
* Where in the assembly do the generated artifacts show up?

> Fix compilation errors when building hbase-spark against Spark 2.0
> --
>
> Key: HBASE-16179
> URL: https://issues.apache.org/jira/browse/HBASE-16179
> Project: HBase
>  Issue Type: Bug
>  Components: spark
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: 16179.v0.txt, 16179.v10.txt, 16179.v11.txt, 
> 16179.v12.txt, 16179.v12.txt, 16179.v12.txt, 16179.v13.txt, 16179.v15.txt, 
> 16179.v16.txt, 16179.v18.txt, 16179.v19.txt, 16179.v19.txt, 16179.v1.txt, 
> 16179.v1.txt, 16179.v4.txt, 16179.v5.txt, 16179.v7.txt, 16179.v8.txt, 
> 16179.v9.txt
>
>
> I tried building hbase-spark module against Spark-2.0 snapshot and got the 
> following compilation errors:
> http://pastebin.com/bg3w247a
> Some Spark classes such as DataTypeParser and Logging are no longer 
> accessible to downstream projects.
> hbase-spark module should not depend on such classes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17350) Fixup of regionserver group-based assignment

2017-01-18 Thread Francis Liu (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828893#comment-15828893
 ] 

Francis Liu commented on HBASE-17350:
-

{quote}
The error message you get when you run one of these rsgroup commands should 
tell you how to set up rsgroups rather than dump out a cryptic exception.
{quote}
I think part of it is because a stacktrace is being dumped. Some exceptions 
messages cryptic but some have decent messages.

> Fixup of regionserver group-based assignment
> 
>
> Key: HBASE-17350
> URL: https://issues.apache.org/jira/browse/HBASE-17350
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: stack
>Priority: Critical
> Fix For: 2.0.0
>
>
> Can we do some fixup on the regionserver group-based assignement before it 
> makes it into a release? Here are a few items after trying to use it last 
> night:
> + The commands are named inconsistently. Usually it is verb with a rsgroup 
> suffix but we have get_table_rsgroups and then move_rsgoup_tables. Ditto for 
> servers.
> + In local mode, the regionserver doesn't belong to a group. Shouldn't it?
> + Adding a server to a group with the move_rsgroup_tables is non-intuitive, 
> to me at least (especially given #2 above).
> + The error message you get when you run one of these rsgroup commands should 
> tell you how to set up rsgroups rather than dump out a cryptic exception.
> Thats all for now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17475) Stack overflow in AsyncProcess if retry too much

2017-01-18 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828894#comment-15828894
 ] 

Hudson commented on HBASE-17475:


FAILURE: Integrated in Jenkins build HBase-1.3-JDK8 #96 (See 
[https://builds.apache.org/job/HBase-1.3-JDK8/96/])
HBASE-17475 Stack overflow in AsyncProcess if retry too much (Allan (tedyu: rev 
f840bd196fd696621d61c75875f5d2d1d996dd0f)
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncProcess.java


> Stack overflow in AsyncProcess if retry too much
> 
>
> Key: HBASE-17475
> URL: https://issues.apache.org/jira/browse/HBASE-17475
> Project: HBase
>  Issue Type: Bug
>  Components: API, Client
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Allan Yang
>Assignee: Allan Yang
>  Labels: trivial
> Fix For: 2.0.0, 1.4.0, 1.3.1
>
> Attachments: HBASE-17475-branch-1.patch, 
> HBASE-17475-branch-1.v2.patch, HBASE-17475-branch-1.v3.patch, 
> HBASE-17475.patch, HBASE-17475.v2.patch
>
>
> In AsyncProcess, we resubmit the retry task in the same thread
> {code}
>   // run all the runnables
>   for (Runnable runnable : runnables) {
> if ((--actionsRemaining == 0) && reuseThread) {
>   runnable.run();
> } else {
>   try {
> pool.submit(runnable);
>   } 
>   ..
> {code}
> But, if we retry too much time. soon, stack overflow will occur. This is very 
> common in clusters with Phoenix. Phoenix need to write index table in the 
> normal write path, retry will cause stack overflow exception.
> {noformat}
> "htable-pool19-t2" #582 daemon prio=5 os_prio=0 tid=0x02687800 
> nid=0x4a96 waiting on condition [0x7fe3f6301000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
>   at java.lang.Thread.sleep(Native Method)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.resubmit(AsyncProcess.java:1174)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.receiveMultiAction(AsyncProcess.java:1321)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.access$1200(AsyncProcess.java:575)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl$SingleServerRequestRunnable.run(AsyncProcess.java:729)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.sendMultiAction(AsyncProcess.java:977)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.groupAndSendMultiAction(AsyncProcess.java:886)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.resubmit(AsyncProcess.java:1181)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.receiveMultiAction(AsyncProcess.java:1321)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.access$1200(AsyncProcess.java:575)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl$SingleServerRequestRunnable.run(AsyncProcess.java:729)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.sendMultiAction(AsyncProcess.java:977)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.groupAndSendMultiAction(AsyncProcess.java:886)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.resubmit(AsyncProcess.java:1181)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.receiveMultiAction(AsyncProcess.java:1321)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.access$1200(AsyncProcess.java:575)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl$SingleServerRequestRunnable.run(AsyncProcess.java:729)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.sendMultiAction(AsyncProcess.java:977)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.groupAndSendMultiAction(AsyncProcess.java:886)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.resubmit(AsyncProcess.java:1181)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.receiveMultiAction(AsyncProcess.java:1321)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.access$1200(AsyncProcess.java:575)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl$SingleServerRequestRunnable.run(AsyncProcess.java:729)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.sendMultiAction(AsyncProcess.java:977)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.groupAndSendMultiAction(AsyncProcess.java:886)
>   at 
>

[jira] [Commented] (HBASE-17350) Fixup of regionserver group-based assignment

2017-01-18 Thread Francis Liu (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828892#comment-15828892
 ] 

Francis Liu commented on HBASE-17350:
-

{quote}
In local mode, the regionserver doesn't belong to a group. Shouldn't it?
{quote}
Why not? You can still have some amount of isolation with groups. ie block 
cache, rpc, etc.


> Fixup of regionserver group-based assignment
> 
>
> Key: HBASE-17350
> URL: https://issues.apache.org/jira/browse/HBASE-17350
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: stack
>Priority: Critical
> Fix For: 2.0.0
>
>
> Can we do some fixup on the regionserver group-based assignement before it 
> makes it into a release? Here are a few items after trying to use it last 
> night:
> + The commands are named inconsistently. Usually it is verb with a rsgroup 
> suffix but we have get_table_rsgroups and then move_rsgoup_tables. Ditto for 
> servers.
> + In local mode, the regionserver doesn't belong to a group. Shouldn't it?
> + Adding a server to a group with the move_rsgroup_tables is non-intuitive, 
> to me at least (especially given #2 above).
> + The error message you get when you run one of these rsgroup commands should 
> tell you how to set up rsgroups rather than dump out a cryptic exception.
> Thats all for now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17350) Fixup of regionserver group-based assignment

2017-01-18 Thread Francis Liu (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828887#comment-15828887
 ] 

Francis Liu commented on HBASE-17350:
-

{quote}
The commands are named inconsistently. Usually it is verb with a rsgroup suffix 
but we have get_table_rsgroups and then move_rsgoup_tables. Ditto for servers.
{quote}
The rsgroup used here is not a "suffix" but actually part of describing the 
command. So you'd like to keep the suffix in the same place? 

ie
get_table_rsgroup - get a table's rsgroup
move_rsgoup_tables - move to rsgroup some tables
move_rsgroup_servers - move to rsgroup some servers


> Fixup of regionserver group-based assignment
> 
>
> Key: HBASE-17350
> URL: https://issues.apache.org/jira/browse/HBASE-17350
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: stack
>Priority: Critical
> Fix For: 2.0.0
>
>
> Can we do some fixup on the regionserver group-based assignement before it 
> makes it into a release? Here are a few items after trying to use it last 
> night:
> + The commands are named inconsistently. Usually it is verb with a rsgroup 
> suffix but we have get_table_rsgroups and then move_rsgoup_tables. Ditto for 
> servers.
> + In local mode, the regionserver doesn't belong to a group. Shouldn't it?
> + Adding a server to a group with the move_rsgroup_tables is non-intuitive, 
> to me at least (especially given #2 above).
> + The error message you get when you run one of these rsgroup commands should 
> tell you how to set up rsgroups rather than dump out a cryptic exception.
> Thats all for now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17484) Add non cached version of OffheapKV for write path

2017-01-18 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828886#comment-15828886
 ] 

stack commented on HBASE-17484:
---

Any evidence to present to justify why we should have these new types? We've 
gone this route a bunch of times in our history adding caching and then undoing 
it.  The argument is that reading these lengths by parsing offheap bytes is 
slow?

After this patch, how many versions of KeyValue do we have?

Do we have to have a OffheapKeyValue and Cached... ? Do we have to realize the 
storage in the Type? Isn't it enough having a ByteBufferCell with it internally 
doing direct or non-direct?

This looks odd... private static final int FIXED_OVERHEAD =
39OffheapKeyValue.FIXED_OVERHEAD + +Bytes.SIZEOF_INT + 
Bytes.SIZEOF_SHORT;   is that a double '+'?



> Add non cached version of OffheapKV for write path
> --
>
> Key: HBASE-17484
> URL: https://issues.apache.org/jira/browse/HBASE-17484
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-17484.patch
>
>
> After running lot of different performance tests for various scenarios and 
> with multi threads we thought that is  better to have a version of OffheapKV 
> in write path that does not cache anything and its fixed_overhead is equal to 
> that in KeyValue. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12894) Upgrade Jetty to 9.2.6

2017-01-18 Thread Sean Busbey (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828883#comment-15828883
 ] 

Sean Busbey commented on HBASE-12894:
-

Thanks for the update! the licensing changes look good. Could you take a look 
at the findbugs issue that got flagged?

> Upgrade Jetty to 9.2.6
> --
>
> Key: HBASE-12894
> URL: https://issues.apache.org/jira/browse/HBASE-12894
> Project: HBase
>  Issue Type: Improvement
>  Components: REST, UI
>Affects Versions: 0.98.0
>Reporter: Rick Hallihan
>Assignee: Guang Yang
>Priority: Critical
>  Labels: MicrosoftSupport
> Fix For: 2.0.0
>
> Attachments: dependency_list_after, dependency_list_before, 
> HBASE-12894_Jetty9_v0.patch, HBASE-12894_Jetty9_v10.patch, 
> HBASE-12894_Jetty9_v1.patch, HBASE-12894_Jetty9_v1.patch, 
> HBASE-12894_Jetty9_v2.patch, HBASE-12894_Jetty9_v3.patch, 
> HBASE-12894_Jetty9_v4.patch, HBASE-12894_Jetty9_v5.patch, 
> HBASE-12894_Jetty9_v6.patch, HBASE-12894_Jetty9_v7.patch, 
> HBASE-12894_Jetty9_v8.patch
>
>
> The Jetty component that is used for the HBase Stargate REST endpoint is 
> version 6.1.26 and is fairly outdated. We recently had a customer inquire 
> about enabling cross-origin resource sharing (CORS) for the REST endpoint and 
> found that this older version does not include the necessary filter or 
> configuration options, highlighted at: 
> http://wiki.eclipse.org/Jetty/Feature/Cross_Origin_Filter
> The Jetty project has had significant updates through versions 7, 8 and 9, 
> including a transition to be an Eclipse subproject, so updating to the latest 
> version may be non-trivial. The last update to the Jetty component in 
> https://issues.apache.org/jira/browse/HBASE-3377 was a minor version update 
> and did not require significant work. This update will include a package 
> namespace update so there will likely be a larger number of required changes. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17486) Tighten the contract for batch client methods

2017-01-18 Thread Michael Axiak (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Axiak updated HBASE-17486:
--
Fix Version/s: 2.1.0
   2.0.0

> Tighten the contract for batch client methods
> -
>
> Key: HBASE-17486
> URL: https://issues.apache.org/jira/browse/HBASE-17486
> Project: HBase
>  Issue Type: Bug
>  Components: API
>Reporter: Michael Axiak
>Priority: Trivial
> Fix For: 2.0.0, 2.1.0
>
> Attachments: HBASE-17486.patch
>
>
> Right now, the API documentation for Table#get(List) and Table#batch(List, 
> Result[]) both leave open the possibility for the ordering of the result 
> array to be independent of the input actions.
> In at least the batch method case, ordering of the result array is important 
> in order to know which partial requests failed in the event of an exception. 
> Since that contact is required in the batch case, I think it should be 
> extended to the get(List) case as well to make the API easier.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17486) Tighten the contract for batch client methods

2017-01-18 Thread Michael Axiak (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Axiak updated HBASE-17486:
--
Status: Patch Available  (was: Open)

> Tighten the contract for batch client methods
> -
>
> Key: HBASE-17486
> URL: https://issues.apache.org/jira/browse/HBASE-17486
> Project: HBase
>  Issue Type: Bug
>  Components: API
>Reporter: Michael Axiak
>Priority: Trivial
> Fix For: 2.0.0, 2.1.0
>
> Attachments: HBASE-17486.patch
>
>
> Right now, the API documentation for Table#get(List) and Table#batch(List, 
> Result[]) both leave open the possibility for the ordering of the result 
> array to be independent of the input actions.
> In at least the batch method case, ordering of the result array is important 
> in order to know which partial requests failed in the event of an exception. 
> Since that contact is required in the batch case, I think it should be 
> extended to the get(List) case as well to make the API easier.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17486) Tighten the contract for batch client methods

2017-01-18 Thread Michael Axiak (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Axiak updated HBASE-17486:
--
Attachment: HBASE-17486.patch

> Tighten the contract for batch client methods
> -
>
> Key: HBASE-17486
> URL: https://issues.apache.org/jira/browse/HBASE-17486
> Project: HBase
>  Issue Type: Bug
>  Components: API
>Reporter: Michael Axiak
>Priority: Trivial
> Attachments: HBASE-17486.patch
>
>
> Right now, the API documentation for Table#get(List) and Table#batch(List, 
> Result[]) both leave open the possibility for the ordering of the result 
> array to be independent of the input actions.
> In at least the batch method case, ordering of the result array is important 
> in order to know which partial requests failed in the event of an exception. 
> Since that contact is required in the batch case, I think it should be 
> extended to the get(List) case as well to make the API easier.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17486) Tighten the contract for batch client methods

2017-01-18 Thread Michael Axiak (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Axiak updated HBASE-17486:
--
Labels: documentation  (was: )

> Tighten the contract for batch client methods
> -
>
> Key: HBASE-17486
> URL: https://issues.apache.org/jira/browse/HBASE-17486
> Project: HBase
>  Issue Type: Bug
>  Components: API
>Reporter: Michael Axiak
>Priority: Trivial
>  Labels: documentation
> Fix For: 2.0.0, 2.1.0
>
> Attachments: HBASE-17486.patch
>
>
> Right now, the API documentation for Table#get(List) and Table#batch(List, 
> Result[]) both leave open the possibility for the ordering of the result 
> array to be independent of the input actions.
> In at least the batch method case, ordering of the result array is important 
> in order to know which partial requests failed in the event of an exception. 
> Since that contact is required in the batch case, I think it should be 
> extended to the get(List) case as well to make the API easier.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17486) Tighten the contract for batch client methods

2017-01-18 Thread Michael Axiak (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Axiak updated HBASE-17486:
--
Flags: Patch

> Tighten the contract for batch client methods
> -
>
> Key: HBASE-17486
> URL: https://issues.apache.org/jira/browse/HBASE-17486
> Project: HBase
>  Issue Type: Bug
>  Components: API
>Reporter: Michael Axiak
>Priority: Trivial
>
> Right now, the API documentation for Table#get(List) and Table#batch(List, 
> Result[]) both leave open the possibility for the ordering of the result 
> array to be independent of the input actions.
> In at least the batch method case, ordering of the result array is important 
> in order to know which partial requests failed in the event of an exception. 
> Since that contact is required in the batch case, I think it should be 
> extended to the get(List) case as well to make the API easier.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-17486) Tighten the contract for batch client methods

2017-01-18 Thread Michael Axiak (JIRA)

Michael Axiak created HBASE-17486:
-

 Summary: Tighten the contract for batch client methods
 Key: HBASE-17486
 URL: https://issues.apache.org/jira/browse/HBASE-17486
 Project: HBase
  Issue Type: Bug
  Components: API
Reporter: Michael Axiak
Priority: Trivial


Right now, the API documentation for Table#get(List) and Table#batch(List, 
Result[]) both leave open the possibility for the ordering of the result array 
to be independent of the input actions.

In at least the batch method case, ordering of the result array is important in 
order to know which partial requests failed in the event of an exception. Since 
that contact is required in the batch case, I think it should be extended to 
the get(List) case as well to make the API easier.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17165) Add retry to LoadIncrementalHFiles tool

2017-01-18 Thread Mike Grimes (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Grimes updated HBASE-17165:

Status: Patch Available  (was: Reopened)

> Add retry to LoadIncrementalHFiles tool
> ---
>
> Key: HBASE-17165
> URL: https://issues.apache.org/jira/browse/HBASE-17165
> Project: HBase
>  Issue Type: Improvement
>  Components: hbase, HFile, tooling
>Affects Versions: 1.2.3, 2.0.0
>Reporter: Mike Grimes
>Assignee: Mike Grimes
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17165.branch-1.001.patch, 
> HBASE-17165.branch-1.2.001.patch, HBASE-17165.branch-1.2.002.patch, 
> HBASE-17165.branch-1.2.003.patch, HBASE-17165.branch-1.2.004.patch, 
> HBASE-17165.master.001.patch, HBASE-17165.master.002.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> As using the LoadIncrementalHFiles tool with S3 as the filesystem is prone to 
> failing due to FileNotFoundExceptions due to inconsistency, simple, 
> configurable retry logic was added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17165) Add retry to LoadIncrementalHFiles tool

2017-01-18 Thread Mike Grimes (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Grimes updated HBASE-17165:

Attachment: HBASE-17165.branch-1.001.patch

> Add retry to LoadIncrementalHFiles tool
> ---
>
> Key: HBASE-17165
> URL: https://issues.apache.org/jira/browse/HBASE-17165
> Project: HBase
>  Issue Type: Improvement
>  Components: hbase, HFile, tooling
>Affects Versions: 2.0.0, 1.2.3
>Reporter: Mike Grimes
>Assignee: Mike Grimes
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17165.branch-1.001.patch, 
> HBASE-17165.branch-1.2.001.patch, HBASE-17165.branch-1.2.002.patch, 
> HBASE-17165.branch-1.2.003.patch, HBASE-17165.branch-1.2.004.patch, 
> HBASE-17165.master.001.patch, HBASE-17165.master.002.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> As using the LoadIncrementalHFiles tool with S3 as the filesystem is prone to 
> failing due to FileNotFoundExceptions due to inconsistency, simple, 
> configurable retry logic was added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17165) Add retry to LoadIncrementalHFiles tool

2017-01-18 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828737#comment-15828737
 ] 

stack commented on HBASE-17165:
---

[~grimesmi] Post here boss add branch-1 into the patch name so we get a run 
against target branch.

> Add retry to LoadIncrementalHFiles tool
> ---
>
> Key: HBASE-17165
> URL: https://issues.apache.org/jira/browse/HBASE-17165
> Project: HBase
>  Issue Type: Improvement
>  Components: hbase, HFile, tooling
>Affects Versions: 2.0.0, 1.2.3
>Reporter: Mike Grimes
>Assignee: Mike Grimes
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17165.branch-1.2.001.patch, 
> HBASE-17165.branch-1.2.002.patch, HBASE-17165.branch-1.2.003.patch, 
> HBASE-17165.branch-1.2.004.patch, HBASE-17165.master.001.patch, 
> HBASE-17165.master.002.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> As using the LoadIncrementalHFiles tool with S3 as the filesystem is prone to 
> failing due to FileNotFoundExceptions due to inconsistency, simple, 
> configurable retry logic was added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (HBASE-17165) Add retry to LoadIncrementalHFiles tool

2017-01-18 Thread stack (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack reopened HBASE-17165:
---

Reopen to try new patch (thanks Mike)

> Add retry to LoadIncrementalHFiles tool
> ---
>
> Key: HBASE-17165
> URL: https://issues.apache.org/jira/browse/HBASE-17165
> Project: HBase
>  Issue Type: Improvement
>  Components: hbase, HFile, tooling
>Affects Versions: 2.0.0, 1.2.3
>Reporter: Mike Grimes
>Assignee: Mike Grimes
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17165.branch-1.2.001.patch, 
> HBASE-17165.branch-1.2.002.patch, HBASE-17165.branch-1.2.003.patch, 
> HBASE-17165.branch-1.2.004.patch, HBASE-17165.master.001.patch, 
> HBASE-17165.master.002.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> As using the LoadIncrementalHFiles tool with S3 as the filesystem is prone to 
> failing due to FileNotFoundExceptions due to inconsistency, simple, 
> configurable retry logic was added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-16786) Procedure V2 - Move ZK-lock's uses to Procedure framework locks (LockProcedure)

2017-01-18 Thread stack (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-16786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-16786:
--
Attachment: HBASE-16786.master.011.patch

> Procedure V2 - Move ZK-lock's uses to Procedure framework locks 
> (LockProcedure)
> ---
>
> Key: HBASE-16786
> URL: https://issues.apache.org/jira/browse/HBASE-16786
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Appy
>Assignee: Matteo Bertozzi
> Attachments: HBASE-16786.master.001.patch, 
> HBASE-16786.master.002.patch, HBASE-16786.master.003.patch, 
> HBASE-16786.master.004.patch, HBASE-16786.master.005.patch, 
> HBASE-16786.master.006.patch, HBASE-16786.master.007.patch, 
> HBASE-16786.master.008.patch, HBASE-16786.master.009.patch, 
> HBASE-16786.master.010.patch, HBASE-16786.master.011.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-16786) Procedure V2 - Move ZK-lock's uses to Procedure framework locks (LockProcedure)

2017-01-18 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-16786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828730#comment-15828730
 ] 

stack commented on HBASE-16786:
---

Rebase after merge removal.

> Procedure V2 - Move ZK-lock's uses to Procedure framework locks 
> (LockProcedure)
> ---
>
> Key: HBASE-16786
> URL: https://issues.apache.org/jira/browse/HBASE-16786
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Appy
>Assignee: Matteo Bertozzi
> Attachments: HBASE-16786.master.001.patch, 
> HBASE-16786.master.002.patch, HBASE-16786.master.003.patch, 
> HBASE-16786.master.004.patch, HBASE-16786.master.005.patch, 
> HBASE-16786.master.006.patch, HBASE-16786.master.007.patch, 
> HBASE-16786.master.008.patch, HBASE-16786.master.009.patch, 
> HBASE-16786.master.010.patch, HBASE-16786.master.011.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17470) Remove merge region code from region server

2017-01-18 Thread Appy (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828708#comment-15828708
 ] 

Appy commented on HBASE-17470:
--

We should probably delete the old CP functions because it's not like the 
functionality is deprecated, it is not there anymore in the first place.
Keeping them risks silent failure which CP devs might have hard time figuring 
out, whereas removing them will throw compile error and prompt active fix.

> Remove merge region code from region server
> ---
>
> Key: HBASE-17470
> URL: https://issues.apache.org/jira/browse/HBASE-17470
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Stephen Yuan Jiang
>Assignee: Stephen Yuan Jiang
> Fix For: 2.0.0
>
> Attachments: HBASE-17470.v1-master.patch, 
> HBASE-17470.v2-master.patch, HBASE-17470.v3-master.patch
>
>
> HBASE-16119 moves the merge region to the master-side.  There is no need to 
> keep region_server-side merge region code to remove logic duplication.  
> util.Merge and HMerge tools depends on RS-side merge region logic.  However, 
> now we can merge regions using shell command.  It is dangerous to do offline 
> merge.  For 2.0, it is a good time to remove those out-of-date tools.   



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17482) mvcc mechanism fails when using mvccPreAssign

2017-01-18 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828641#comment-15828641
 ] 

Hudson commented on HBASE-17482:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #2342 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/2342/])
HBASE-17482 mvcc mechanism fails when using mvccPreAssign (Allan Yang) (tedyu: 
rev 6cbc375aa493b159600996b86d3872e9db16f6c6)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide3.java


> mvcc mechanism fails when using mvccPreAssign
> -
>
> Key: HBASE-17482
> URL: https://issues.apache.org/jira/browse/HBASE-17482
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0..
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-17482.patch, HBASE-17482.v2.patch, 
> HBASE-17482.v3.patch
>
>
> If mvccPreAssign and ASYNC_WAL is used, then cells may have been commited to 
> memstore before append thread can stamp seqid to them. The unit test shows 
> everything.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17460) enable_table_replication can not perform cyclic replication of a table

2017-01-18 Thread NITIN VERMA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828637#comment-15828637
 ] 

NITIN VERMA commented on HBASE-17460:
-

[~enis] [~ashish singhi] Does the new patch look fine to you? 


> enable_table_replication can not perform cyclic replication of a table
> --
>
> Key: HBASE-17460
> URL: https://issues.apache.org/jira/browse/HBASE-17460
> Project: HBase
>  Issue Type: Bug
>  Components: Replication
>Reporter: NITIN VERMA
>Assignee: NITIN VERMA
>  Labels: replication
> Attachments: HBASE-17460.patch, HBASE-17460_v2.patch
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> The enable_table_replication operation is broken for cyclic replication of 
> HBase table as we compare all the properties of column families (including 
> REPLICATION_SCOPE). 
> Below is exactly what happens:
> 1.  Running "enable_table_replication 'table1'  " opeartion on first cluster 
> will set the REPLICATION_SCOPE of all column families to peer id '1'. This 
> will also create a table on second cluster where REPLICATION_SCOPE is still 
> set to peer id '0'.
> 2. Now when we run "enable_table_replication 'table1'" on second cluster, we 
> compare all the properties of table (including REPLICATION_SCOPE_, which 
> obviously is different now. 
> I am proposing a fix for this issue where we should avoid comparing 
> REPLICATION_SCOPE inside HColumnDescriotor::compareTo() method, especially 
> when replication is not already enabled on the desired table.
> I have made that change and it is working. I will submit the patch soon.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-13788) Shell commands do not support column qualifiers containing colon (:)

2017-01-18 Thread Jean-Marc Spaggiari (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828631#comment-15828631
 ] 

Jean-Marc Spaggiari commented on HBASE-13788:
-

I like this approach. It breaks compatibility, so might be tagged as 2.0 I 
guess?

[~stack]?

> Shell commands do not support column qualifiers containing colon (:)
> 
>
> Key: HBASE-13788
> URL: https://issues.apache.org/jira/browse/HBASE-13788
> Project: HBase
>  Issue Type: Bug
>  Components: shell
>Affects Versions: 0.98.0, 0.96.0, 1.0.0, 1.1.0
>Reporter: Dave Latham
>Assignee: Manaswini
>
> The shell interprets the colon within the qualifier as a delimiter to a 
> FORMATTER instead of part of the qualifier itself.
> Example from the mailing list:
> Hmph, I may have spoken too soon. I know I tested this at one point and
> it worked, but now I'm getting different results:
> On the new cluster, I created a duplicate test table:
> hbase(main):043:0> create 'content3', {NAME => 'x', BLOOMFILTER =>
> 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '3', COMPRESSION =>
> 'NONE', MIN_VERSIONS => '0', TTL => '2147483647', BLOCKSIZE => '65536',
> IN_MEMORY => 'false', BLOCKCACHE => 'true'}
> Then I pull some data from the imported table:
> hbase(main):045:0> scan 'content', {LIMIT=>1,
> STARTROW=>'A:9223370612089311807:twtr:57013379'}
> ROW  COLUMN+CELL
> 
> A:9223370612089311807:twtr:570133798827921408
> column=x:twitter:username, timestamp=1424775595345, value=BERITA &
> INFORMASI!
> Then put it:
> hbase(main):046:0> put
> 'content3','A:9223370612089311807:twtr:570133798827921408',
> 'x:twitter:username', 'BERITA & INFORMASI!'
> But then when I query it, I see that I've lost the column qualifier
> ":username":
> hbase(main):046:0> scan 'content3'
> ROW  COLUMN+CELL
>  A:9223370612089311807:twtr:570133798827921408 column=x:twitter,
>  timestamp=1432745301788, value=BERITA & INFORMASI!
> Even though I'm missing one of the qualifiers, I can at least filter on
> columns in this sample table.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-13788) Shell commands do not support column qualifiers containing colon (:)

2017-01-18 Thread Manaswini (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828585#comment-15828585
 ] 

Manaswini commented on HBASE-13788:
---

Thank you [~busbey] & stack

I've played with the code and implemented the idea of adding a formatting 
directive as a separate argument instead of passing it along the column 
qualifier. Below are a few examples for existing and changed code - 

hbase(main):003:0> scan 'content3'
ROW   COLUMN+CELL   


 A:9223370612089311807:twtr:57013379882792140 column=x:twitter:username, 
timestamp=1484764832937, value=BERITA & INFORMASI!  
   
 9  


1 row(s)

With existing code (cf:qualifier:[CONVERTER])
hbase(main):003:0>  get 
'content3','A:9223370612089311807:twtr:570133798827921409',{COLUMN => 
'x:twitter:toInt'}
COLUMN   CELL   
   
 x:twitter   timestamp=1484755000607, value=839305  
   
1 row(s) in 0.0140 seconds

hbase(main):003:0> scan 'content3' ,{COLUMN => 'x:twitter:toInt'}
ROW  COLUMN+CELL
   
 A:9223370612089311807:twtr:57013379 column=x:twitter, timestamp=1484755000607, 
value=839305   
 8827921409 
   
1 row(s) in 0.4960 seconds

hbase(main):003:0> scan 'content3' ,{COLUMN => 'x:twitter:username'}
ROW  COLUMN+CELL
   

ERROR: undefined method `username' for class `#'

-

With changed code (separate FORMATTER tag)
hbase(main):017:0> get 
'content3','A:9223370612089311807:twtr:570133798827921409',{COLUMN => 
['x:twitter:username'] , FORMATTER => {'x:twitter:username'=>'toInt'}} 
COLUMNCELL  


 x:twitter:username   timestamp=1484754351711, 
value=839305
 
1 row(s)

hbase(main):017:0>  scan 'content3',{COLUMN => ['x:twitter:username'] , 
FORMATTER => {'x:twitter:username'=>'toInt'}} 
ROW   COLUMN+CELL   


 A:9223370612089311807:twtr:57013379882792140 column=x:twitter:username, 
timestamp=1484764832937, value=839305   
   
 9  


1 row(s)

hbase(main):017:0>  scan 'content3',{COLUMN => ['x:twitter:username'] }
ROW   COLUMN+CELL   


 A:9223370612089311807:twtr:57013379882792140 column=x:twitter:username, 
timestamp=1484764832937, value=BERITA & INFORMASI!  
   
 9  



Does this look good? 

Once I get thumbs-up from stack, I shall build the patch, add test cases for 
get and scan along with proper comments and send it over for code review.


> Shell commands do not support column qualifiers containing colon (:)
> 
>
> Key: HBASE-13788
> URL: https://issues.apache.org/jira/browse/HBASE-13788
> Project: HBase
>  Issue Type: Bug
>  Components: shell
>Affects Versions: 0.98.0, 0.96.0, 1.0.0, 1.1.0
>Reporter: Dave Latham
>Assignee: Manaswini
>
> The shell interprets the colon within the qualifier as a delimiter to a 
> FORMATTER instead of part of the qualifier itself.
> Example from the mailing

[jira] [Commented] (HBASE-17165) Add retry to LoadIncrementalHFiles tool

2017-01-18 Thread Mike Grimes (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828527#comment-15828527
 ] 

Mike Grimes commented on HBASE-17165:
-

Hey [~stack], I've got a patch for branch-1 that applied to branch-1.3 as well. 
Should I open a new JIRA for the backport? Or would you like me to submit it 
here?

> Add retry to LoadIncrementalHFiles tool
> ---
>
> Key: HBASE-17165
> URL: https://issues.apache.org/jira/browse/HBASE-17165
> Project: HBase
>  Issue Type: Improvement
>  Components: hbase, HFile, tooling
>Affects Versions: 2.0.0, 1.2.3
>Reporter: Mike Grimes
>Assignee: Mike Grimes
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17165.branch-1.2.001.patch, 
> HBASE-17165.branch-1.2.002.patch, HBASE-17165.branch-1.2.003.patch, 
> HBASE-17165.branch-1.2.004.patch, HBASE-17165.master.001.patch, 
> HBASE-17165.master.002.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> As using the LoadIncrementalHFiles tool with S3 as the filesystem is prone to 
> failing due to FileNotFoundExceptions due to inconsistency, simple, 
> configurable retry logic was added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-17101) FavoredNodes should not apply to system tables

2017-01-18 Thread Thiruvel Thirumoolan (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828524#comment-15828524
 ] 

Thiruvel Thirumoolan commented on HBASE-17101:
--

The unit test failure hadoop.hbase.client.TestZKAsyncRegistry is unrelated to 
the patch.

> FavoredNodes should not apply to system tables
> --
>
> Key: HBASE-17101
> URL: https://issues.apache.org/jira/browse/HBASE-17101
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Thiruvel Thirumoolan
>Assignee: Thiruvel Thirumoolan
> Fix For: 2.0.0
>
> Attachments: HBASE-17101.master.001.patch, 
> HBASE-17101.master.002.patch, HBASE-17101.master.003.patch, 
> HBASE-17101.master.004.patch, HBASE_17101_rough_draft.patch
>
>
> As described in the doc (see HBASE-15531), we would like to start with user 
> tables for favored nodes. This task ensures FN does not apply to system 
> tables.
> System tables are in memory and won't benefit from favored nodes. Since we 
> also maintain FN information for user regions in meta, it helps to keep 
> implementation simpler by ignoring system tables for the first iterations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-17475) Stack overflow in AsyncProcess if retry too much

2017-01-18 Thread Ted Yu (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-17475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-17475:
---
Fix Version/s: 1.3.1

> Stack overflow in AsyncProcess if retry too much
> 
>
> Key: HBASE-17475
> URL: https://issues.apache.org/jira/browse/HBASE-17475
> Project: HBase
>  Issue Type: Bug
>  Components: API, Client
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Allan Yang
>Assignee: Allan Yang
>  Labels: trivial
> Fix For: 2.0.0, 1.4.0, 1.3.1
>
> Attachments: HBASE-17475-branch-1.patch, 
> HBASE-17475-branch-1.v2.patch, HBASE-17475-branch-1.v3.patch, 
> HBASE-17475.patch, HBASE-17475.v2.patch
>
>
> In AsyncProcess, we resubmit the retry task in the same thread
> {code}
>   // run all the runnables
>   for (Runnable runnable : runnables) {
> if ((--actionsRemaining == 0) && reuseThread) {
>   runnable.run();
> } else {
>   try {
> pool.submit(runnable);
>   } 
>   ..
> {code}
> But, if we retry too much time. soon, stack overflow will occur. This is very 
> common in clusters with Phoenix. Phoenix need to write index table in the 
> normal write path, retry will cause stack overflow exception.
> {noformat}
> "htable-pool19-t2" #582 daemon prio=5 os_prio=0 tid=0x02687800 
> nid=0x4a96 waiting on condition [0x7fe3f6301000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
>   at java.lang.Thread.sleep(Native Method)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.resubmit(AsyncProcess.java:1174)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.receiveMultiAction(AsyncProcess.java:1321)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.access$1200(AsyncProcess.java:575)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl$SingleServerRequestRunnable.run(AsyncProcess.java:729)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.sendMultiAction(AsyncProcess.java:977)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.groupAndSendMultiAction(AsyncProcess.java:886)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.resubmit(AsyncProcess.java:1181)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.receiveMultiAction(AsyncProcess.java:1321)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.access$1200(AsyncProcess.java:575)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl$SingleServerRequestRunnable.run(AsyncProcess.java:729)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.sendMultiAction(AsyncProcess.java:977)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.groupAndSendMultiAction(AsyncProcess.java:886)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.resubmit(AsyncProcess.java:1181)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.receiveMultiAction(AsyncProcess.java:1321)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.access$1200(AsyncProcess.java:575)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl$SingleServerRequestRunnable.run(AsyncProcess.java:729)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.sendMultiAction(AsyncProcess.java:977)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.groupAndSendMultiAction(AsyncProcess.java:886)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.resubmit(AsyncProcess.java:1181)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.receiveMultiAction(AsyncProcess.java:1321)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.access$1200(AsyncProcess.java:575)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl$SingleServerRequestRunnable.run(AsyncProcess.java:729)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.sendMultiAction(AsyncProcess.java:977)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.groupAndSendMultiAction(AsyncProcess.java:886)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.resubmit(AsyncProcess.java:1181)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.receiveMultiAction(AsyncProcess.java:1321)
>   at 
> org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl.access$1200(AsyncProcess.java:575)
>   at 
>

[jira] [Commented] (HBASE-17482) mvcc mechanism fails when using mvccPreAssign

2017-01-18 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828336#comment-15828336
 ] 

Hadoop QA commented on HBASE-17482:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 13s 
{color} | {color:blue} Docker mode activated. {color} |
| {color: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} 3m 
0s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
42s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
45s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
42s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
25m 4s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
48s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 78m 54s 
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
13s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 115m 44s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12848064/HBASE-17482.v3.patch |
| JIRA Issue | HBASE-17482 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux db3aced420bc 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12 
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
 |
| git revision | master / 406f66a |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5316/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5316/console |
| Powered by | Apache Yetus 0.3.0   http://yetus.apache.org |


This message was automatically generated.



> mvcc mechanism fails when using mvccPreAssign
> -
>
> Key: HBASE-17482
> URL: https://issues.apache.org/jira/browse/HBASE-17482
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0..
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-17482.patch, HBASE-17482.v2.patch, 
>

[jira] [Commented] (HBASE-17484) Add non cached version of OffheapKV for write path

2017-01-18 Thread Ted Yu (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-17484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828322#comment-15828322
 ] 

Ted Yu commented on HBASE-17484:


Looks good overall.
{code}
26   * This Cell is an implementation of {@link ByteBufferCell} where the 
data resides in off heap
{code}
The above javadoc seems to be copied from OffheapKeyValue.

I think mentioning OffheapKeyValue is more appropriate.

> Add non cached version of OffheapKV for write path
> --
>
> Key: HBASE-17484
> URL: https://issues.apache.org/jira/browse/HBASE-17484
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-17484.patch
>
>
> After running lot of different performance tests for various scenarios and 
> with multi threads we thought that is  better to have a version of OffheapKV 
> in write path that does not cache anything and its fixed_overhead is equal to 
> that in KeyValue. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

1 2 >

1 - 100 of 157 matches

Mail list logo