[jira] [Commented] (HBASE-19223) Remove references to Date Tiered compaction from branch-1.2 and branch-1.1 ref guide

[Yu Li (JIRA)]

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

Yu Li commented on HBASE-19223:
---

+1, checked the patch and doc looks great. It seems UT timed out but should be 
irrelative to change here.

> Remove references to Date Tiered compaction from branch-1.2 and branch-1.1 
> ref guide
> 
>
> Key: HBASE-19223
> URL: https://issues.apache.org/jira/browse/HBASE-19223
> Project: HBase
>  Issue Type: Bug
>  Components: Compaction, documentation
>Affects Versions: 1.1.5, 1.2.2
>Reporter: chilianyi
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 1.2.7, 1.1.13
>
> Attachments: HBASE-19223-branch-1.2.v0.patch, 
> HBASE-19223-branch-1.2.v1.patch
>
>
> I have download hbase 1.2.6 src package. But not found class 
> DateTieredStoreEngine, which is  present in document: 
> https://hbase.apache.org/1.2/book.html. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19262) Revisit checkstyle rules

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-19262:
---

| (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:brown} Prechecks {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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
47s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
10s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
48s{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  
3s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m  
9s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m  
8s{color} | {color:green} hbase-checkstyle in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
 9s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 10m 36s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19262 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12897697/HBASE-19262.patch |
| Optional Tests |  asflicense  javac  javadoc  unit  xml  |
| uname | Linux da032d553542 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11 
12:48:20 UTC 2017 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 / 249bc09d8d |
| maven | version: Apache Maven 3.5.2 
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9818/testReport/ |
| modules | C: hbase-checkstyle U: hbase-checkstyle |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9818/console |
| Powered by | Apache Yetus 0.6.0   http://yetus.apache.org |


This message was automatically generated.



> Revisit checkstyle rules
> 
>
> Key: HBASE-19262
> URL: https://issues.apache.org/jira/browse/HBASE-19262
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Attachments: HBASE-19262.patch
>
>
> For the shaded imports, I prefer we put it at the bottom with a separated 
> block. And also, for UTs which use junit rule, we usually declare the field 
> as public but checkstyle will report a VisibilityModifier problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18964) Deprecate RowProcessor and processRowsWithLocks() APIs that take RowProcessor as an argument

[Umesh Agashe (JIRA)]

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

Umesh Agashe updated HBASE-18964:
-
Status: Patch Available  (was: In Progress)

> Deprecate RowProcessor and processRowsWithLocks() APIs that take RowProcessor 
> as an argument
> 
>
> Key: HBASE-18964
> URL: https://issues.apache.org/jira/browse/HBASE-18964
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0-alpha-3
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0-beta-1
>
> Attachments: hbase-18964.master.001.patch
>
>
> Deprecate RowProcessor and processRowsWithLocks() APIs that take RowProcessor 
> as an argument



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18964) Deprecate RowProcessor and processRowsWithLocks() APIs that take RowProcessor as an argument

[Umesh Agashe (JIRA)]

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

Umesh Agashe updated HBASE-18964:
-
Attachment: hbase-18964.master.001.patch

> Deprecate RowProcessor and processRowsWithLocks() APIs that take RowProcessor 
> as an argument
> 
>
> Key: HBASE-18964
> URL: https://issues.apache.org/jira/browse/HBASE-18964
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0-alpha-3
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0-beta-1
>
> Attachments: hbase-18964.master.001.patch
>
>
> Deprecate RowProcessor and processRowsWithLocks() APIs that take RowProcessor 
> as an argument



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19262) Revisit checkstyle rules

[Duo Zhang (JIRA)]

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

Duo Zhang updated HBASE-19262:
--
Attachment: HBASE-19262.patch

> Revisit checkstyle rules
> 
>
> Key: HBASE-19262
> URL: https://issues.apache.org/jira/browse/HBASE-19262
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Duo Zhang
> Attachments: HBASE-19262.patch
>
>
> For the shaded imports, I prefer we put it at the bottom with a separated 
> block. And also, for UTs which use junit rule, we usually declare the field 
> as public but checkstyle will report a VisibilityModifier problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19262) Revisit checkstyle rules

[Duo Zhang (JIRA)]

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

Duo Zhang updated HBASE-19262:
--
Assignee: Duo Zhang
  Status: Patch Available  (was: Open)

> Revisit checkstyle rules
> 
>
> Key: HBASE-19262
> URL: https://issues.apache.org/jira/browse/HBASE-19262
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Attachments: HBASE-19262.patch
>
>
> For the shaded imports, I prefer we put it at the bottom with a separated 
> block. And also, for UTs which use junit rule, we usually declare the field 
> as public but checkstyle will report a VisibilityModifier problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18964) Deprecate RowProcessor and processRowsWithLocks() APIs that take RowProcessor as an argument

[Umesh Agashe (JIRA)]

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

Umesh Agashe commented on HBASE-18964:
--

[~anoop.hbase], we can let it go through one release cycle for deprecation and 
remove it in 3.0.0.

> Deprecate RowProcessor and processRowsWithLocks() APIs that take RowProcessor 
> as an argument
> 
>
> Key: HBASE-18964
> URL: https://issues.apache.org/jira/browse/HBASE-18964
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0-alpha-3
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0-beta-1
>
>
> Deprecate RowProcessor and processRowsWithLocks() APIs that take RowProcessor 
> as an argument



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18964) Deprecate RowProcessor and processRowsWithLocks() APIs that take RowProcessor as an argument

[Umesh Agashe (JIRA)]

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

Umesh Agashe updated HBASE-18964:
-
Release Note: RowProcessor and Region#processRowsWithLocks() methods that 
take RowProcessor as an argument are deprecated.

> Deprecate RowProcessor and processRowsWithLocks() APIs that take RowProcessor 
> as an argument
> 
>
> Key: HBASE-18964
> URL: https://issues.apache.org/jira/browse/HBASE-18964
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0-alpha-3
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0-beta-1
>
>
> Deprecate RowProcessor and processRowsWithLocks() APIs that take RowProcessor 
> as an argument



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19223) Remove references to Date Tiered compaction from branch-1.2 and branch-1.1 ref guide

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-19223:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
12s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @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:brown} branch-1.2 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  7m 
53s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  1m 
38s{color} | {color:green} branch-1.2 passed with JDK v1.8.0_141 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  2m  
2s{color} | {color:green} branch-1.2 passed with JDK v1.7.0_151 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  1m 
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} javadoc {color} | {color:green}  1m 
32s{color} | {color:green} the patch passed with JDK v1.8.0_141 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  2m  
9s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}1614m  2s{color} 
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
22s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}1631m 21s{color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:f29f170 |
| JIRA Issue | HBASE-19223 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12897224/HBASE-19223-branch-1.2.v1.patch
 |
| Optional Tests |  asflicense  javac  javadoc  unit  |
| uname | Linux dc132ff9ff14 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 | branch-1.2 / c2d154c |
| maven | version: Apache Maven 3.0.5 |
| Default Java | 1.7.0_151 |
| Multi-JDK versions |  /usr/lib/jvm/java-8-openjdk-amd64:1.8.0_141 
/usr/lib/jvm/java-7-openjdk-amd64:1.7.0_151 |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9788/artifact/patchprocess/patch-unit-root.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9788/testReport/ |
| modules | C: . U: . |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9788/console |
| Powered by | Apache Yetus 0.6.0   http://yetus.apache.org |


This message was automatically generated.



> Remove references to Date Tiered compaction from branch-1.2 and branch-1.1 
> ref guide
> 
>
> Key: HBASE-19223
> URL: https://issues.apache.org/jira/browse/HBASE-19223
> Project: HBase
>  Issue Type: Bug
>  Components: Compaction, documentation
>Affects Versions: 1.1.5, 1.2.2
>Reporter: chilianyi
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 1.2.7, 1.1.13
>
> Attachments: HBASE-19223-branch-1.2.v0.patch, 
> HBASE-19223-branch-1.2.v1.patch
>
>
> I have download hbase 1.2.6 src package. But not found class 
> DateTieredStoreEngine, which is  present in document: 
> https://hbase.apache.org/1.2/book.html. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19260) Add lock back to avoid parallel accessing meta to locate region

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-19260:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m  
9s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  0m  
0s{color} | {color:blue} Findbugs executables are not available. {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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
19s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
 6s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
19s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
39s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
52m 16s{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 2.7.4 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
20s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
43s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
 9s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 71m 13s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19260 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12897680/HBASE-19260.v2.patch |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 7ce22eafaf58 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11 
12:48:20 UTC 2017 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 / 797670b129 |
| maven | version: Apache Maven 3.5.2 
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9814/testReport/ |
| modules | C: hbase-client U: hbase-client |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9814/console |
| Powered by | Apache Yetus 0.6.0   http://yetus.apache.org |


This message was automatically generated.



> Add lock back to avoid parallel accessing meta to locate 

[jira] [Comment Edited] (HBASE-19262) Revisit checkstyle rules

[Reid Chan (JIRA)]

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

Reid Chan edited comment on HBASE-19262 at 11/15/17 7:29 AM:
-

bq. For the shaded imports, I prefer we put it at the bottom with a separated 
block.
Agree. Old version of check-style was as your description, code base is mixed 
with two styles now.


was (Author: reidchan):
bq. For the shaded imports, I prefer we put it at the bottom with a separated 
block.
Agree. Old version of check-style is as your description, code base is mixed 
with two styles now.

> Revisit checkstyle rules
> 
>
> Key: HBASE-19262
> URL: https://issues.apache.org/jira/browse/HBASE-19262
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Duo Zhang
>
> For the shaded imports, I prefer we put it at the bottom with a separated 
> block. And also, for UTs which use junit rule, we usually declare the field 
> as public but checkstyle will report a VisibilityModifier problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19114) Split out o.a.h.h.zookeeper from hbase-server and hbase-client

[Duo Zhang (JIRA)]

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

Duo Zhang commented on HBASE-19114:
---

My only concern before is we should not add more dependencies for hbase-client. 
After HBASE-19200 we do not need to make hbase-client depend on the new 
hbase-zookeeper module so I'm OK with this change.

Thanks.

> Split out o.a.h.h.zookeeper from hbase-server and hbase-client
> --
>
> Key: HBASE-19114
> URL: https://issues.apache.org/jira/browse/HBASE-19114
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19114.master.001.patch, 
> HBASE-19114.master.002.patch, HBASE-19114.master.003.patch, 
> HBASE-19114.master.004.patch, HBASE-19114.master.005.patch, 
> HBASE-19114.master.006.patch
>
>
> Changes so far:
> - Moved DrainingServerTracker and RegionServerTracker to 
> hbase-server:o.a.h.h.master.
> - Moved SplitOrMergeTracker to oahh.master (because it depends on a PB)
> - Moving hbase-client:oahh.zookeeper.*  to hbase-zookeeper module.  After 
> [~Apache9]'s cleanup (HBASE-19200), hbase-client doesn't need them anymore 
> (except 3 classes).
> - Renamed some classes to use a consistent naming for classes - ZK instead of 
> mix of ZK, Zk , ZooKeeper. Couldn't rename following public classes: 
> MiniZooKeeperCluster, ZooKeeperConnectionException. Left RecoverableZooKeeper 
> for lack of better name. (suggestions?)
> - Sadly, can't move tests out because they depend on HBaseTestingUtility 
> (which defeats part of the purpose - trimming down hbase-server tests. We 
> need to promote more use of mocks in our tests)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18978) Align the methods in Table and AsyncTable

[Duo Zhang (JIRA)]

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

Duo Zhang commented on HBASE-18978:
---

{quote}
one seemed like, get all result and use consumer to process them, in async way
other one is more like, streaming results and processing simultaneously, with 
ability to stop-start scan on will.
{quote}

For the normal consumer, it is also in a streaming way, but the model is very 
simple, pass the result one by one to the consumer. And you can return false in 
onNext to terminate the scan.
And the implementation is also straight-forward, create a ResultScanner and 
read result one by one and then call consumer.onNext. 
For the raw consumer, the model is much more complex. The stop-start is 
necessary. As you are not allowed to do time consuming work in all the methods, 
a typical way is to cache the result and process them with another thread. An 
example is AsyncTableResultScanner. So you need to stop fetching when memory is 
full, and resume the fetching when memory is free enough. And we also expose 
onHeartbeat to tell user that RS is still alive but we do not have enough data 
to call onNext.

Thanks.

> Align the methods in Table and AsyncTable
> -
>
> Key: HBASE-18978
> URL: https://issues.apache.org/jira/browse/HBASE-18978
> Project: HBase
>  Issue Type: Task
>  Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Peter Somogyi
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19262) Revisit checkstyle rules

[Reid Chan (JIRA)]

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

Reid Chan commented on HBASE-19262:
---

bq. For the shaded imports, I prefer we put it at the bottom with a separated 
block.
Agree. Old version of check-style is as your description, code base is mixed 
with two styles now.

> Revisit checkstyle rules
> 
>
> Key: HBASE-19262
> URL: https://issues.apache.org/jira/browse/HBASE-19262
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Duo Zhang
>
> For the shaded imports, I prefer we put it at the bottom with a separated 
> block. And also, for UTs which use junit rule, we usually declare the field 
> as public but checkstyle will report a VisibilityModifier problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18963) Remove MultiRowMutationProcessor and implement mutateRows... methods using batchMutate()

[Umesh Agashe (JIRA)]

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

Umesh Agashe commented on HBASE-18963:
--

Thanks [~stack]! added release notes.

> Remove MultiRowMutationProcessor and implement mutateRows... methods using 
> batchMutate()
> 
>
> Key: HBASE-18963
> URL: https://issues.apache.org/jira/browse/HBASE-18963
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0-alpha-3
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0-beta-1
>
> Attachments: hbase-18963.master.001.patch, 
> hbase-18963.master.002.patch, hbase-18963.master.003.patch, 
> hbase-18963.master.004.patch, hbase-18963.master.005.patch, 
> hbase-18963.master.005.patch
>
>
> Remove MultiRowMutationProcessor and implement mutateRows... methods using 
> batchMutate()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18963) Remove MultiRowMutationProcessor and implement mutateRows... methods using batchMutate()

[Umesh Agashe (JIRA)]

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

Umesh Agashe updated HBASE-18963:
-
Release Note: Modified HRegion.mutateRow() APIs to use batchMutate() 
instead of processRowsWithLocks() with MultiRowMutationProcessor. 
MultiRowMutationProcessor is removed to have single write path that uses 
batchMutate().

> Remove MultiRowMutationProcessor and implement mutateRows... methods using 
> batchMutate()
> 
>
> Key: HBASE-18963
> URL: https://issues.apache.org/jira/browse/HBASE-18963
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0-alpha-3
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0-beta-1
>
> Attachments: hbase-18963.master.001.patch, 
> hbase-18963.master.002.patch, hbase-18963.master.003.patch, 
> hbase-18963.master.004.patch, hbase-18963.master.005.patch, 
> hbase-18963.master.005.patch
>
>
> Remove MultiRowMutationProcessor and implement mutateRows... methods using 
> batchMutate()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19255) PerformanceEvaluation class not found when run PE test

[Guanghao Zhang (JIRA)]

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

Guanghao Zhang updated HBASE-19255:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> PerformanceEvaluation class not found when run PE test
> --
>
> Key: HBASE-19255
> URL: https://issues.apache.org/jira/browse/HBASE-19255
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 3.0.0, 2.0.0-beta-1
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 3.0.0, 2.0.0-beta-1
>
> Attachments: HBASE-19255.master.001.patch
>
>
> {code}
> mvn clean package install -DskipTests
> ./hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=1 --nomapred 
> randomWrite 1
> {code}
> PerformanceEvaluation is in hbase-mapreduce module's test jar. After 
> HBASE-18640, we move mapreduce out of hbase-server into separate 
> hbase-mapreduce module. But didn't add the hbase-mapreduce test jar to 
> hbase-assembly pom.xml. So it didn't add to the default classpath. Then the 
> PerformanceEvaluation can't found.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19114) Split out o.a.h.h.zookeeper from hbase-server and hbase-client

[Peter Somogyi (JIRA)]

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

Peter Somogyi commented on HBASE-19114:
---

Is release note needed for this change?

> Split out o.a.h.h.zookeeper from hbase-server and hbase-client
> --
>
> Key: HBASE-19114
> URL: https://issues.apache.org/jira/browse/HBASE-19114
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19114.master.001.patch, 
> HBASE-19114.master.002.patch, HBASE-19114.master.003.patch, 
> HBASE-19114.master.004.patch, HBASE-19114.master.005.patch, 
> HBASE-19114.master.006.patch
>
>
> Changes so far:
> - Moved DrainingServerTracker and RegionServerTracker to 
> hbase-server:o.a.h.h.master.
> - Moved SplitOrMergeTracker to oahh.master (because it depends on a PB)
> - Moving hbase-client:oahh.zookeeper.*  to hbase-zookeeper module.  After 
> [~Apache9]'s cleanup (HBASE-19200), hbase-client doesn't need them anymore 
> (except 3 classes).
> - Renamed some classes to use a consistent naming for classes - ZK instead of 
> mix of ZK, Zk , ZooKeeper. Couldn't rename following public classes: 
> MiniZooKeeperCluster, ZooKeeperConnectionException. Left RecoverableZooKeeper 
> for lack of better name. (suggestions?)
> - Sadly, can't move tests out because they depend on HBaseTestingUtility 
> (which defeats part of the purpose - trimming down hbase-server tests. We 
> need to promote more use of mocks in our tests)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19009) implement modifyTable and enable/disableTableReplication for AsyncAdmin

[Guanghao Zhang (JIRA)]

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

Guanghao Zhang updated HBASE-19009:
---
Attachment: HBASE-19009.master.012.patch

> implement modifyTable and enable/disableTableReplication for AsyncAdmin
> ---
>
> Key: HBASE-19009
> URL: https://issues.apache.org/jira/browse/HBASE-19009
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 3.0.0, 2.0.0-beta-1
>
> Attachments: HBASE-19009.master.001.patch, 
> HBASE-19009.master.002.patch, HBASE-19009.master.003.patch, 
> HBASE-19009.master.004.patch, HBASE-19009.master.005.patch, 
> HBASE-19009.master.006.patch, HBASE-19009.master.007.patch, 
> HBASE-19009.master.008.patch, HBASE-19009.master.009.patch, 
> HBASE-19009.master.010.patch, HBASE-19009.master.011.patch, 
> HBASE-19009.master.012.patch
>
>
> Add 3 methods to AsyncAdmin.
> modifyTable()
> enableTableReplication()
> disableTableReplication()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19251) Merge RawAsyncTable and AsyncTable

[Duo Zhang (JIRA)]

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

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

Fix failed UTs, also the checkstyle and javadoc issues.

> Merge RawAsyncTable and AsyncTable
> --
>
> Key: HBASE-19251
> URL: https://issues.apache.org/jira/browse/HBASE-19251
> Project: HBase
>  Issue Type: Improvement
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Attachments: HBASE-19251-v1.patch, HBASE-19251.patch
>
>
> As discussed in HBASE-18978.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19262) Revisit checkstyle rules

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-19262:
-

 Summary: Revisit checkstyle rules
 Key: HBASE-19262
 URL: https://issues.apache.org/jira/browse/HBASE-19262
 Project: HBase
  Issue Type: Improvement
  Components: build
Reporter: Duo Zhang


For the shaded imports, I prefer we put it at the bottom with a separated 
block. And also, for UTs which use junit rule, we usually declare the field as 
public but checkstyle will report a VisibilityModifier problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-19092:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m  
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  8s{color} 
| {color:red} HBASE-19092 does not apply to branch-2. Rebase required? Wrong 
Branch? See https://yetus.apache.org/documentation/0.6.0/precommit-patchnames 
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-19092 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12897681/HBASE-19092.branch-2.0.02.patch
 |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9815/console |
| Powered by | Apache Yetus 0.6.0   http://yetus.apache.org |


This message was automatically generated.



> Make Tag IA.LimitedPrivate and expose for CPs
> -
>
> Key: HBASE-19092
> URL: https://issues.apache.org/jira/browse/HBASE-19092
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19092-branch-2.patch, 
> HBASE-19092-branch-2_5.patch, HBASE-19092-branch-2_5.patch, 
> HBASE-19092.branch-2.0.02.patch, HBASE-19092_001-branch-2.patch, 
> HBASE-19092_002-branch-2.patch
>
>
> We need to make tags as LimitedPrivate as some use cases are trying to use 
> tags like timeline server. The same topic was discussed in dev@ and also in 
> HBASE-18995.
> Shall we target this for beta1 - cc [~saint@gmail.com].
> So once we do this all related Util methods and APIs should also move to 
> LimitedPrivate Util classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs

[stack (JIRA)]

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

stack commented on HBASE-19092:
---

bq. Tag.asList(Cell) 

This sounds like a good idea. Better if CPs don't have to know how Cell is 
backed.

Thanks for taking a look [~ram_krish] 

Once this is committed, I'll make a patch for Timeline Server as an 
exercise...

> Make Tag IA.LimitedPrivate and expose for CPs
> -
>
> Key: HBASE-19092
> URL: https://issues.apache.org/jira/browse/HBASE-19092
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19092-branch-2.patch, 
> HBASE-19092-branch-2_5.patch, HBASE-19092-branch-2_5.patch, 
> HBASE-19092.branch-2.0.02.patch, HBASE-19092_001-branch-2.patch, 
> HBASE-19092_002-branch-2.patch
>
>
> We need to make tags as LimitedPrivate as some use cases are trying to use 
> tags like timeline server. The same topic was discussed in dev@ and also in 
> HBASE-18995.
> Shall we target this for beta1 - cc [~saint@gmail.com].
> So once we do this all related Util methods and APIs should also move to 
> LimitedPrivate Util classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18357) Enable disabled tests in TestHCM that were disabled by Proc-V2 AM in HBASE-14614

[stack (JIRA)]

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

stack commented on HBASE-18357:
---

Been working on these failures. They are interesting.

TestRegionCaching fails because the regionserver closing region can't report 
into the master; it has one handler only running. hbase2 has RS do RPC into 
Master now other than the heartbeating to report status. Master needs to be 
able to take the call (This test suite had handler count == 1 for one test 
only... odd. I moved it out to be its own test suite). Also exception thrown 
when we try Put to a RegionServer was problematic. We had lost facility where 
if a region is being moved, we'd throw a RegionMovedException. I fixed this. 
Also, the exception now is RetriesExhaustedException rather than 
RetriesExhaustedWithDetailsException. This may be a problem but has to do w/ 
changes allowing AsyncTable and Table share some client processing. Will keep 
an eye on it.

Fixing above seems to have fixed TestMulti (as per Vladimir above).

Was working on TestClusterStatus. It fails because it depends on the old 
multicast facility that broadcast to clients dead servers. Filed HBASE-19261 
because I couldn't get it going again.. needs more attention. Patch coming...

> Enable disabled tests in TestHCM that were disabled by Proc-V2 AM in 
> HBASE-14614
> 
>
> Key: HBASE-18357
> URL: https://issues.apache.org/jira/browse/HBASE-18357
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Affects Versions: 2.0.0-alpha-1
>Reporter: Stephen Yuan Jiang
>Assignee: Vladimir Rodionov
> Attachments: HBASE-18357-v1.patch
>
>
> The Core Proc-V2 AM change in HBASE-14614 disabled two tests inTestHCM: 
> testMulti and testRegionCaching
> This JIRA tracks the work to enable them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan updated HBASE-19092:
---
Status: Patch Available  (was: Open)

> Make Tag IA.LimitedPrivate and expose for CPs
> -
>
> Key: HBASE-19092
> URL: https://issues.apache.org/jira/browse/HBASE-19092
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19092-branch-2.patch, 
> HBASE-19092-branch-2_5.patch, HBASE-19092-branch-2_5.patch, 
> HBASE-19092.branch-2.0.02.patch, HBASE-19092_001-branch-2.patch, 
> HBASE-19092_002-branch-2.patch
>
>
> We need to make tags as LimitedPrivate as some use cases are trying to use 
> tags like timeline server. The same topic was discussed in dev@ and also in 
> HBASE-18995.
> Shall we target this for beta1 - cc [~saint@gmail.com].
> So once we do this all related Util methods and APIs should also move to 
> LimitedPrivate Util classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan updated HBASE-19092:
---
Attachment: HBASE-19092.branch-2.0.02.patch

Renamed patch. 

> Make Tag IA.LimitedPrivate and expose for CPs
> -
>
> Key: HBASE-19092
> URL: https://issues.apache.org/jira/browse/HBASE-19092
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19092-branch-2.patch, 
> HBASE-19092-branch-2_5.patch, HBASE-19092-branch-2_5.patch, 
> HBASE-19092.branch-2.0.02.patch, HBASE-19092_001-branch-2.patch, 
> HBASE-19092_002-branch-2.patch
>
>
> We need to make tags as LimitedPrivate as some use cases are trying to use 
> tags like timeline server. The same topic was discussed in dev@ and also in 
> HBASE-18995.
> Shall we target this for beta1 - cc [~saint@gmail.com].
> So once we do this all related Util methods and APIs should also move to 
> LimitedPrivate Util classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19260) Add lock back to avoid parallel accessing meta to locate region

[Yu Li (JIRA)]

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

Yu Li updated HBASE-19260:
--
Attachment: HBASE-19260.v2.patch

Resolve the checkstyle issue:
{noformat}
Method length is 155 lines (max allowed is 150). [MethodLength]
{noformat}

> Add lock back to avoid parallel accessing meta to locate region
> ---
>
> Key: HBASE-19260
> URL: https://issues.apache.org/jira/browse/HBASE-19260
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.3.1, 1.2.6, 2.0.0-alpha-3, 1.1.12
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-19260.patch, HBASE-19260.v2.patch
>
>
> In branch-0.98 we have below codes to avoid accessing meta in parallel in 
> {{HConnectionManager}}:
> {code}
>   Result regionInfoRow;
>   // This block guards against two threads trying to load the meta
>   // region at the same time. The first will load the meta region and
>   // the second will use the value that the first one found.
>   if (useCache) {
> if (TableName.META_TABLE_NAME.equals(parentTable) && usePrefetch 
> &&
> getRegionCachePrefetch(tableName)) {
>   synchronized (regionLockObject) {
> // Check the cache again for a hit in case some other thread 
> made the
> // same query while we were waiting on the lock.
> ...
>   }
> }
>   ...
> {code}
> while in HBASE-10018 we removed such logic along with 
> region-location-prefetching. 
> We regard this as an unexpected behavior change and observed below phenomenon 
> in our product env:
> 1. Unnecessary connection setup to meta when multiple threads locating region 
> in a client process
> 2. Priority handler of the RS holding meta region exhausted, application keep 
> retrying and cause a vicious circle
> To resolve this problem, we propose to add the {{userRegionLock}} back and 
> keep the behavior in accordance with 0.98



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan updated HBASE-19092:
---
Status: Open  (was: Patch Available)

> Make Tag IA.LimitedPrivate and expose for CPs
> -
>
> Key: HBASE-19092
> URL: https://issues.apache.org/jira/browse/HBASE-19092
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19092-branch-2.patch, 
> HBASE-19092-branch-2_5.patch, HBASE-19092-branch-2_5.patch, 
> HBASE-19092_001-branch-2.patch, HBASE-19092_002-branch-2.patch
>
>
> We need to make tags as LimitedPrivate as some use cases are trying to use 
> tags like timeline server. The same topic was discussed in dev@ and also in 
> HBASE-18995.
> Shall we target this for beta1 - cc [~saint@gmail.com].
> So once we do this all related Util methods and APIs should also move to 
> LimitedPrivate Util classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19261) ClusterStatusPublisher where Master could optionally broadcast notice of dead servers is broke

[stack (JIRA)]

stack created HBASE-19261:
-

 Summary: ClusterStatusPublisher where Master could optionally 
broadcast notice of dead servers is broke
 Key: HBASE-19261
 URL: https://issues.apache.org/jira/browse/HBASE-19261
 Project: HBase
  Issue Type: Bug
  Components: MTTR
Reporter: stack


An old feature that you could optionally enable so Master would broadcast via 
UDP/Multicast messages to registered clients when it learned of dead servers is 
broken in hbase2. It was added here:

commit c352a848a1af318df4f0348728fb136ce289d3e4
Author: nkeywal 
Date:   Tue Mar 19 10:07:17 2013 +

HBASE-7590 Add a costless notifications mechanism from master to 
regionservers & clients - new files

It could help the recalibration of clients on server death run quicker. I have 
not stats on how often it was use if at all.

I tried playing around with it to try and get it going again but need to spend 
more time on it. Putting aside for now. 

We should make it work again and then talk it up as a mechanism that can help 
improve MTTR (or strip it).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19253) Dynamic change MemStoreFlusher FlushHandler workers

[binlijin (JIRA)]

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

binlijin commented on HBASE-19253:
--

bq. How is the max determined ?
Just random select.
bq. When would the if block be executed ? It seems once the sleep is executed, 
subsequent iterations would always sleep.
The handlerCount can be changed when update_config. First start 8 (default) 
FlushHandler workers and only 2 do the flush the others just sleep,   when 
handlerCount changed dynamic, the number of workers can do flush changed.
bq. getFlusherThreadNum -> getFlusherThreadCount
OK.
bq. The second if can be 'else if'
OK.



> Dynamic change MemStoreFlusher FlushHandler workers
> ---
>
> Key: HBASE-19253
> URL: https://issues.apache.org/jira/browse/HBASE-19253
> Project: HBase
>  Issue Type: Improvement
>Reporter: binlijin
>Assignee: binlijin
> Attachments: HBASE-19253.master.001.patch, 
> HBASE-19253.master.002.patch
>
>
> Use update_config to dynamic change MemStoreFlusher FlushHandler workers



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19245) MultiTableInputFormatBase#getSplits creates a Connection per Table

[Hudson (JIRA)]

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

Hudson commented on HBASE-19245:


FAILURE: Integrated in Jenkins build HBase-1.3-IT #287 (See 
[https://builds.apache.org/job/HBase-1.3-IT/287/])
HBASE-19245 MultiTableInputFormatBase#getSplits creates a Connection per 
(stack: rev 17f11ae6c8e4c1be520167eb5b22d61b05a49c9f)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/MultiTableInputFormatBase.java


> MultiTableInputFormatBase#getSplits creates a Connection per Table
> --
>
> Key: HBASE-19245
> URL: https://issues.apache.org/jira/browse/HBASE-19245
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Reporter: stack
>Assignee: stack
>Priority: Minor
> Fix For: 1.4.0, 1.3.2, 2.0.0-beta-1
>
> Attachments: HBASE-19245.branch-2.001.patch, 
> HBASE-19245.branch-2.002.patch, HBASE-19245.branch-2.003.patch, 
> HBASE-19245.branch-2.004.patch
>
>
> Doesn't have to. Connection setup costs. Shared Connection could save on 
> hbase:meta hits (perhaps).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19245) MultiTableInputFormatBase#getSplits creates a Connection per Table

[Hudson (JIRA)]

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

Hudson commented on HBASE-19245:


FAILURE: Integrated in Jenkins build HBase-1.5 #159 (See 
[https://builds.apache.org/job/HBase-1.5/159/])
HBASE-19245 MultiTableInputFormatBase#getSplits creates a Connection per 
(stack: rev 641e797e02ef1285de8b8efc8d48989c686d42bd)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/MultiTableInputFormatBase.java


> MultiTableInputFormatBase#getSplits creates a Connection per Table
> --
>
> Key: HBASE-19245
> URL: https://issues.apache.org/jira/browse/HBASE-19245
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Reporter: stack
>Assignee: stack
>Priority: Minor
> Fix For: 1.4.0, 1.3.2, 2.0.0-beta-1
>
> Attachments: HBASE-19245.branch-2.001.patch, 
> HBASE-19245.branch-2.002.patch, HBASE-19245.branch-2.003.patch, 
> HBASE-19245.branch-2.004.patch
>
>
> Doesn't have to. Connection setup costs. Shared Connection could save on 
> hbase:meta hits (perhaps).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19253) Dynamic change MemStoreFlusher FlushHandler workers

[binlijin (JIRA)]

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

binlijin updated HBASE-19253:
-
Attachment: HBASE-19253.master.002.patch

> Dynamic change MemStoreFlusher FlushHandler workers
> ---
>
> Key: HBASE-19253
> URL: https://issues.apache.org/jira/browse/HBASE-19253
> Project: HBase
>  Issue Type: Improvement
>Reporter: binlijin
>Assignee: binlijin
> Attachments: HBASE-19253.master.001.patch, 
> HBASE-19253.master.002.patch
>
>
> Use update_config to dynamic change MemStoreFlusher FlushHandler workers



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-19092:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m  
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  5s{color} 
| {color:red} HBASE-19092 does not apply to branch-2. Rebase required? Wrong 
Branch? See https://yetus.apache.org/documentation/0.6.0/precommit-patchnames 
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-19092 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12897677/HBASE-19092_002-branch-2.patch
 |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9813/console |
| Powered by | Apache Yetus 0.6.0   http://yetus.apache.org |


This message was automatically generated.



> Make Tag IA.LimitedPrivate and expose for CPs
> -
>
> Key: HBASE-19092
> URL: https://issues.apache.org/jira/browse/HBASE-19092
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19092-branch-2.patch, 
> HBASE-19092-branch-2_5.patch, HBASE-19092-branch-2_5.patch, 
> HBASE-19092_001-branch-2.patch, HBASE-19092_002-branch-2.patch
>
>
> We need to make tags as LimitedPrivate as some use cases are trying to use 
> tags like timeline server. The same topic was discussed in dev@ and also in 
> HBASE-18995.
> Shall we target this for beta1 - cc [~saint@gmail.com].
> So once we do this all related Util methods and APIs should also move to 
> LimitedPrivate Util classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan commented on HBASE-19092:


So in another JIRA I saw a discussion about RawCell and ExtendedCell (I think 
if we want to move some APIs in ExtendedCell like write() then we need them to 
be moved to RawCell). All server Cells will be of type RawCell. 

> Make Tag IA.LimitedPrivate and expose for CPs
> -
>
> Key: HBASE-19092
> URL: https://issues.apache.org/jira/browse/HBASE-19092
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19092-branch-2.patch, 
> HBASE-19092-branch-2_5.patch, HBASE-19092-branch-2_5.patch, 
> HBASE-19092_001-branch-2.patch, HBASE-19092_002-branch-2.patch
>
>
> We need to make tags as LimitedPrivate as some use cases are trying to use 
> tags like timeline server. The same topic was discussed in dev@ and also in 
> HBASE-18995.
> Shall we target this for beta1 - cc [~saint@gmail.com].
> So once we do this all related Util methods and APIs should also move to 
> LimitedPrivate Util classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan updated HBASE-19092:
---
Status: Patch Available  (was: Open)

> Make Tag IA.LimitedPrivate and expose for CPs
> -
>
> Key: HBASE-19092
> URL: https://issues.apache.org/jira/browse/HBASE-19092
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19092-branch-2.patch, 
> HBASE-19092-branch-2_5.patch, HBASE-19092-branch-2_5.patch, 
> HBASE-19092_001-branch-2.patch, HBASE-19092_002-branch-2.patch
>
>
> We need to make tags as LimitedPrivate as some use cases are trying to use 
> tags like timeline server. The same topic was discussed in dev@ and also in 
> HBASE-18995.
> Shall we target this for beta1 - cc [~saint@gmail.com].
> So once we do this all related Util methods and APIs should also move to 
> LimitedPrivate Util classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19245) MultiTableInputFormatBase#getSplits creates a Connection per Table

[Hudson (JIRA)]

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

Hudson commented on HBASE-19245:


FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #347 (See 
[https://builds.apache.org/job/HBase-1.3-JDK7/347/])
HBASE-19245 MultiTableInputFormatBase#getSplits creates a Connection per 
(stack: rev 17f11ae6c8e4c1be520167eb5b22d61b05a49c9f)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/MultiTableInputFormatBase.java


> MultiTableInputFormatBase#getSplits creates a Connection per Table
> --
>
> Key: HBASE-19245
> URL: https://issues.apache.org/jira/browse/HBASE-19245
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Reporter: stack
>Assignee: stack
>Priority: Minor
> Fix For: 1.4.0, 1.3.2, 2.0.0-beta-1
>
> Attachments: HBASE-19245.branch-2.001.patch, 
> HBASE-19245.branch-2.002.patch, HBASE-19245.branch-2.003.patch, 
> HBASE-19245.branch-2.004.patch
>
>
> Doesn't have to. Connection setup costs. Shared Connection could save on 
> hbase:meta hits (perhaps).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19245) MultiTableInputFormatBase#getSplits creates a Connection per Table

[Hudson (JIRA)]

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

Hudson commented on HBASE-19245:


FAILURE: Integrated in Jenkins build HBase-1.3-JDK8 #366 (See 
[https://builds.apache.org/job/HBase-1.3-JDK8/366/])
HBASE-19245 MultiTableInputFormatBase#getSplits creates a Connection per 
(stack: rev 17f11ae6c8e4c1be520167eb5b22d61b05a49c9f)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/MultiTableInputFormatBase.java


> MultiTableInputFormatBase#getSplits creates a Connection per Table
> --
>
> Key: HBASE-19245
> URL: https://issues.apache.org/jira/browse/HBASE-19245
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Reporter: stack
>Assignee: stack
>Priority: Minor
> Fix For: 1.4.0, 1.3.2, 2.0.0-beta-1
>
> Attachments: HBASE-19245.branch-2.001.patch, 
> HBASE-19245.branch-2.002.patch, HBASE-19245.branch-2.003.patch, 
> HBASE-19245.branch-2.004.patch
>
>
> Doesn't have to. Connection setup costs. Shared Connection could save on 
> hbase:meta hits (perhaps).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan updated HBASE-19092:
---
Attachment: HBASE-19092_002-branch-2.patch

Retrying QA for branch-2.
The MAX_TAGS_LENGTH is now moved to ExtendedCell. One thing to note is that
-> ExtendedCell now exposed to CPs has APIs like write(OS) , write(BB). This 
may be unwanted for the CPs.
-> The new Tag related APIs in ExtendedCell uses the PrivateCellUtil to do the 
actual impl of the API. I think it is ok to be like that. 

> Make Tag IA.LimitedPrivate and expose for CPs
> -
>
> Key: HBASE-19092
> URL: https://issues.apache.org/jira/browse/HBASE-19092
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19092-branch-2.patch, 
> HBASE-19092-branch-2_5.patch, HBASE-19092-branch-2_5.patch, 
> HBASE-19092_001-branch-2.patch, HBASE-19092_002-branch-2.patch
>
>
> We need to make tags as LimitedPrivate as some use cases are trying to use 
> tags like timeline server. The same topic was discussed in dev@ and also in 
> HBASE-18995.
> Shall we target this for beta1 - cc [~saint@gmail.com].
> So once we do this all related Util methods and APIs should also move to 
> LimitedPrivate Util classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19245) MultiTableInputFormatBase#getSplits creates a Connection per Table

[stack (JIRA)]

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

stack updated HBASE-19245:
--
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 2.0.0-beta-1
   1.3.2
   1.4.0
   Status: Resolved  (was: Patch Available)

Pushed to 1.3+ (Patched file does not exist in 1.2... would have to find the 
equiv).

> MultiTableInputFormatBase#getSplits creates a Connection per Table
> --
>
> Key: HBASE-19245
> URL: https://issues.apache.org/jira/browse/HBASE-19245
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Reporter: stack
>Assignee: stack
>Priority: Minor
> Fix For: 1.4.0, 1.3.2, 2.0.0-beta-1
>
> Attachments: HBASE-19245.branch-2.001.patch, 
> HBASE-19245.branch-2.002.patch, HBASE-19245.branch-2.003.patch, 
> HBASE-19245.branch-2.004.patch
>
>
> Doesn't have to. Connection setup costs. Shared Connection could save on 
> hbase:meta hits (perhaps).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19245) MultiTableInputFormatBase#getSplits creates a Connection per Table

[Hudson (JIRA)]

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

Hudson commented on HBASE-19245:


FAILURE: Integrated in Jenkins build HBase-1.4 #1018 (See 
[https://builds.apache.org/job/HBase-1.4/1018/])
HBASE-19245 MultiTableInputFormatBase#getSplits creates a Connection per 
(stack: rev 846753c185cb6771b7d64cbdae82cbc38e213c94)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/MultiTableInputFormatBase.java


> MultiTableInputFormatBase#getSplits creates a Connection per Table
> --
>
> Key: HBASE-19245
> URL: https://issues.apache.org/jira/browse/HBASE-19245
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Reporter: stack
>Assignee: stack
>Priority: Minor
> Attachments: HBASE-19245.branch-2.001.patch, 
> HBASE-19245.branch-2.002.patch, HBASE-19245.branch-2.003.patch, 
> HBASE-19245.branch-2.004.patch
>
>
> Doesn't have to. Connection setup costs. Shared Connection could save on 
> hbase:meta hits (perhaps).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan updated HBASE-19092:
---
Status: Open  (was: Patch Available)

> Make Tag IA.LimitedPrivate and expose for CPs
> -
>
> Key: HBASE-19092
> URL: https://issues.apache.org/jira/browse/HBASE-19092
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19092-branch-2.patch, 
> HBASE-19092-branch-2_5.patch, HBASE-19092-branch-2_5.patch, 
> HBASE-19092_001-branch-2.patch
>
>
> We need to make tags as LimitedPrivate as some use cases are trying to use 
> tags like timeline server. The same topic was discussed in dev@ and also in 
> HBASE-18995.
> Shall we target this for beta1 - cc [~saint@gmail.com].
> So once we do this all related Util methods and APIs should also move to 
> LimitedPrivate Util classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-15320) HBase connector for Kafka Connect

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-15320:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m  
9s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue}  0m  
6s{color} | {color:blue} Shelldocs was not available. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  0m  
0s{color} | {color:blue} Findbugs executables are not available. {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:brown} master Compile Tests {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}  4m 
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  4m 
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  2m 
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
36s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  2m 
47s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
12s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red}  4m 
20s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red}  3m 
32s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red}  0m  
9s{color} | {color:red} hbase-assembly in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red}  0m 
14s{color} | {color:red} hbase-kafka-proxy in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red}  3m 32s{color} 
| {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red}  0m  9s{color} 
| {color:red} hbase-assembly in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red}  0m 14s{color} 
| {color:red} hbase-kafka-proxy in the patch failed. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  2m 
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green}  0m 
 1s{color} | {color:green} There were no new shellcheck issues. {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red}  0m  
0s{color} | {color:red} The patch has 2 line(s) that end in whitespace. Use git 
apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply 
{color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red}  0m  
0s{color} | {color:red} The patch 1 line(s) with tabs. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green}  0m  
6s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
44s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red}  8m 
30s{color} | {color:red} The patch causes 48 errors with Hadoop v2.6.1. {color} 
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 12m 
15s{color} | {color:red} The patch causes 48 errors with Hadoop v2.6.2. {color} 
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 16m  
2s{color} | {color:red} The patch causes 48 errors with Hadoop v2.6.3. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 19m 
48s{color} | {color:red} The patch causes 48 errors with Hadoop 

[jira] [Updated] (HBASE-18963) Remove MultiRowMutationProcessor and implement mutateRows... methods using batchMutate()

[stack (JIRA)]

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

stack updated HBASE-18963:
--
  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

Pushed to master and branch-2. Thanks [~uagashe]. Stick a release note on it 
boss.

> Remove MultiRowMutationProcessor and implement mutateRows... methods using 
> batchMutate()
> 
>
> Key: HBASE-18963
> URL: https://issues.apache.org/jira/browse/HBASE-18963
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0-alpha-3
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0-beta-1
>
> Attachments: hbase-18963.master.001.patch, 
> hbase-18963.master.002.patch, hbase-18963.master.003.patch, 
> hbase-18963.master.004.patch, hbase-18963.master.005.patch, 
> hbase-18963.master.005.patch
>
>
> Remove MultiRowMutationProcessor and implement mutateRows... methods using 
> batchMutate()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19260) Add lock back to avoid parallel accessing meta to locate region

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-19260:
---

| (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:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  0m  
0s{color} | {color:blue} Findbugs executables are not available. {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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  5m 
19s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
54s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
25s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  5m 
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
21s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  0m 
30s{color} | {color:red} hbase-client: The patch generated 1 new + 8 unchanged 
- 0 fixed = 9 total (was 8) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
16s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
60m  2s{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 2.7.4 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
24s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
53s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
10s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 82m  9s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19260 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12897666/HBASE-19260.patch |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux c73b3023fafc 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11 
12:48:20 UTC 2017 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 / 0c4fbcc329 |
| maven | version: Apache Maven 3.5.2 
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| checkstyle | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9811/artifact/patchprocess/diff-checkstyle-hbase-client.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9811/testReport/ |
| modules | C: hbase-client U: hbase-client |
| Console output | 

[jira] [Commented] (HBASE-19235) CoprocessorEnvironment should be exposed to CPs

[stack (JIRA)]

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

stack commented on HBASE-19235:
---

+1 for v3.

> CoprocessorEnvironment should be exposed to CPs
> ---
>
> Key: HBASE-19235
> URL: https://issues.apache.org/jira/browse/HBASE-19235
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Affects Versions: 2.0.0-alpha-4
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Minor
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19235.patch, HBASE-19235_V2.patch, 
> HBASE-19235_V3.patch, HBASE-19235_V3.patch
>
>
> Its sub interfaces are exposed with 
> LimitedPrivate(HBaseInterfaceAudience.COPROC).  So ideally all the functions 
> in this are.  Better we mark CoprocessorEnvironment also as CP exposed to 
> avoid confusion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19255) PerformanceEvaluation class not found when run PE test

[Guanghao Zhang (JIRA)]

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

Guanghao Zhang commented on HBASE-19255:


Let me commit it later.

> PerformanceEvaluation class not found when run PE test
> --
>
> Key: HBASE-19255
> URL: https://issues.apache.org/jira/browse/HBASE-19255
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 3.0.0, 2.0.0-beta-1
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 3.0.0, 2.0.0-beta-1
>
> Attachments: HBASE-19255.master.001.patch
>
>
> {code}
> mvn clean package install -DskipTests
> ./hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=1 --nomapred 
> randomWrite 1
> {code}
> PerformanceEvaluation is in hbase-mapreduce module's test jar. After 
> HBASE-18640, we move mapreduce out of hbase-server into separate 
> hbase-mapreduce module. But didn't add the hbase-mapreduce test jar to 
> hbase-assembly pom.xml. So it didn't add to the default classpath. Then the 
> PerformanceEvaluation can't found.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19235) CoprocessorEnvironment should be exposed to CPs

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-19235:


+1

> CoprocessorEnvironment should be exposed to CPs
> ---
>
> Key: HBASE-19235
> URL: https://issues.apache.org/jira/browse/HBASE-19235
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Affects Versions: 2.0.0-alpha-4
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Minor
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19235.patch, HBASE-19235_V2.patch, 
> HBASE-19235_V3.patch, HBASE-19235_V3.patch
>
>
> Its sub interfaces are exposed with 
> LimitedPrivate(HBaseInterfaceAudience.COPROC).  So ideally all the functions 
> in this are.  Better we mark CoprocessorEnvironment also as CP exposed to 
> avoid confusion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18309) Support multi threads in CleanerChore

[Reid Chan (JIRA)]

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

Reid Chan updated HBASE-18309:
--
Attachment: HBASE-18309.master.004.patch

* mv {{hbase.cleaner.threadpool.size}} to 
{{hbase.cleaner.scan.dir.concurrent.size}}
* add documentation for {{hbase.cleaner.scan.dir.concurrent.size}}
* keep sorting for (sub)dirs
* support multi threads in {{LogCleaner}} as well
* support online configuration change for both {{CleanerChore}} and 
{{LogCleaner}}
* add tests about online configuration change for both {{CleanerChore}} and 
{{LogCleaner}}, and tests passed locally

As concerned, it's possible for thread flood happen and drag NN down. And i 
have an idea (not quite sure, and need some discussions), but would please 
allow me to file another jira for that, it's too squeezed to put into one patch.

> Support multi threads in CleanerChore
> -
>
> Key: HBASE-18309
> URL: https://issues.apache.org/jira/browse/HBASE-18309
> Project: HBase
>  Issue Type: Improvement
>  Components: wal
>Reporter: binlijin
>Assignee: Reid Chan
> Attachments: HBASE-18309.master.001.patch, 
> HBASE-18309.master.002.patch, HBASE-18309.master.004.patch, 
> space_consumption_in_archive.png
>
>
> There is only one thread in LogCleaner to clean oldWALs and in our big 
> cluster we find this is not enough. The number of files under oldWALs reach 
> the max-directory-items limit of HDFS and cause region server crash, so we 
> use multi threads for LogCleaner and the crash not happened any more.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18309) Support multi threads in CleanerChore

[Reid Chan (JIRA)]

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

Reid Chan updated HBASE-18309:
--
Status: Patch Available  (was: Open)

> Support multi threads in CleanerChore
> -
>
> Key: HBASE-18309
> URL: https://issues.apache.org/jira/browse/HBASE-18309
> Project: HBase
>  Issue Type: Improvement
>  Components: wal
>Reporter: binlijin
>Assignee: Reid Chan
> Attachments: HBASE-18309.master.001.patch, 
> HBASE-18309.master.002.patch, HBASE-18309.master.004.patch, 
> space_consumption_in_archive.png
>
>
> There is only one thread in LogCleaner to clean oldWALs and in our big 
> cluster we find this is not enough. The number of files under oldWALs reach 
> the max-directory-items limit of HDFS and cause region server crash, so we 
> use multi threads for LogCleaner and the crash not happened any more.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-12091) Optionally ignore edits for dropped tables for replication.

[Hudson (JIRA)]

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

Hudson commented on HBASE-12091:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4054 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/4054/])
HBASE-12091 Optionally ignore edits for dropped tables for replication. (larsh: 
rev 0c4fbcc32973e9fb3840cb2b5e397155044c2b0c)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/protobuf/ReplicationProtbufUtil.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/RetriesExhaustedWithDetailsException.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/ReplicationEndpoint.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSink.java
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
* (add) 
hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationDroppedTables.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceManager.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/HBaseInterClusterReplicationEndpoint.java


> Optionally ignore edits for dropped tables for replication.
> ---
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 2.0.0, 3.0.0, 1.4.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt, 
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt, 
> 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, 
> 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091-v9-branch-1.txt, 
> 12091-v9-master.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and 
> the sink, but the source still has outstanding edits that now it could not 
> get rid of. Now all replication is backed up behind these unreplicatable 
> edits.
> We should have an option to ignore edits for tables dropped at the source.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18309) Support multi threads in CleanerChore

[Reid Chan (JIRA)]

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

Reid Chan updated HBASE-18309:
--
Status: Open  (was: Patch Available)

> Support multi threads in CleanerChore
> -
>
> Key: HBASE-18309
> URL: https://issues.apache.org/jira/browse/HBASE-18309
> Project: HBase
>  Issue Type: Improvement
>  Components: wal
>Reporter: binlijin
>Assignee: Reid Chan
> Attachments: HBASE-18309.master.001.patch, 
> HBASE-18309.master.002.patch, space_consumption_in_archive.png
>
>
> There is only one thread in LogCleaner to clean oldWALs and in our big 
> cluster we find this is not enough. The number of files under oldWALs reach 
> the max-directory-items limit of HDFS and cause region server crash, so we 
> use multi threads for LogCleaner and the crash not happened any more.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19257) Document tool to dump information from MasterProcWALs file

[Sean Busbey (JIRA)]

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

Sean Busbey commented on HBASE-19257:
-

before we put docs in the ref guide could we give the utility a short name 
instead of relying on the fully qualified class name?

> Document tool to dump information from MasterProcWALs file
> --
>
> Key: HBASE-19257
> URL: https://issues.apache.org/jira/browse/HBASE-19257
> Project: HBase
>  Issue Type: Improvement
>Reporter: Ted Yu
>
> I was troubleshooting customer case where high number of files piled up under 
> MasterProcWALs directory.
> Gaining insight into (sample) file from MasterProcWALs dir would help find 
> the root cause.
> This JIRA is to document ProcedureWALPrettyPrinter which reads proc wal file 
> and prints (selected) information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19260) Add lock back to avoid parallel accessing meta to locate region

[Yu Li (JIRA)]

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

Yu Li updated HBASE-19260:
--
Status: Patch Available  (was: Open)

Check against HadoopQA

> Add lock back to avoid parallel accessing meta to locate region
> ---
>
> Key: HBASE-19260
> URL: https://issues.apache.org/jira/browse/HBASE-19260
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.1.12, 2.0.0-alpha-3, 1.2.6, 1.3.1
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-19260.patch
>
>
> In branch-0.98 we have below codes to avoid accessing meta in parallel in 
> {{HConnectionManager}}:
> {code}
>   Result regionInfoRow;
>   // This block guards against two threads trying to load the meta
>   // region at the same time. The first will load the meta region and
>   // the second will use the value that the first one found.
>   if (useCache) {
> if (TableName.META_TABLE_NAME.equals(parentTable) && usePrefetch 
> &&
> getRegionCachePrefetch(tableName)) {
>   synchronized (regionLockObject) {
> // Check the cache again for a hit in case some other thread 
> made the
> // same query while we were waiting on the lock.
> ...
>   }
> }
>   ...
> {code}
> while in HBASE-10018 we removed such logic along with 
> region-location-prefetching. 
> We regard this as an unexpected behavior change and observed below phenomenon 
> in our product env:
> 1. Unnecessary connection setup to meta when multiple threads locating region 
> in a client process
> 2. Priority handler of the RS holding meta region exhausted, application keep 
> retrying and cause a vicious circle
> To resolve this problem, we propose to add the {{userRegionLock}} back and 
> keep the behavior in accordance with 0.98



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19260) Add lock back to avoid parallel accessing meta to locate region

[Yu Li (JIRA)]

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

Yu Li commented on HBASE-19260:
---

This is something we found and fixed some time back when migrating from 0.98 to 
1.1, and I just noticed it when reviewing the difference between our current 
code base and community master. Maybe more coming, let's see.

> Add lock back to avoid parallel accessing meta to locate region
> ---
>
> Key: HBASE-19260
> URL: https://issues.apache.org/jira/browse/HBASE-19260
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.3.1, 1.2.6, 2.0.0-alpha-3, 1.1.12
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-19260.patch
>
>
> In branch-0.98 we have below codes to avoid accessing meta in parallel in 
> {{HConnectionManager}}:
> {code}
>   Result regionInfoRow;
>   // This block guards against two threads trying to load the meta
>   // region at the same time. The first will load the meta region and
>   // the second will use the value that the first one found.
>   if (useCache) {
> if (TableName.META_TABLE_NAME.equals(parentTable) && usePrefetch 
> &&
> getRegionCachePrefetch(tableName)) {
>   synchronized (regionLockObject) {
> // Check the cache again for a hit in case some other thread 
> made the
> // same query while we were waiting on the lock.
> ...
>   }
> }
>   ...
> {code}
> while in HBASE-10018 we removed such logic along with 
> region-location-prefetching. 
> We regard this as an unexpected behavior change and observed below phenomenon 
> in our product env:
> 1. Unnecessary connection setup to meta when multiple threads locating region 
> in a client process
> 2. Priority handler of the RS holding meta region exhausted, application keep 
> retrying and cause a vicious circle
> To resolve this problem, we propose to add the {{userRegionLock}} back and 
> keep the behavior in accordance with 0.98



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19260) Add lock back to avoid parallel accessing meta to locate region

[Yu Li (JIRA)]

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

Yu Li updated HBASE-19260:
--
Attachment: HBASE-19260.patch

Uploading a straight forward patch

> Add lock back to avoid parallel accessing meta to locate region
> ---
>
> Key: HBASE-19260
> URL: https://issues.apache.org/jira/browse/HBASE-19260
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.3.1, 1.2.6, 2.0.0-alpha-3, 1.1.12
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-19260.patch
>
>
> In branch-0.98 we have below codes to avoid accessing meta in parallel in 
> {{HConnectionManager}}:
> {code}
>   Result regionInfoRow;
>   // This block guards against two threads trying to load the meta
>   // region at the same time. The first will load the meta region and
>   // the second will use the value that the first one found.
>   if (useCache) {
> if (TableName.META_TABLE_NAME.equals(parentTable) && usePrefetch 
> &&
> getRegionCachePrefetch(tableName)) {
>   synchronized (regionLockObject) {
> // Check the cache again for a hit in case some other thread 
> made the
> // same query while we were waiting on the lock.
> ...
>   }
> }
>   ...
> {code}
> while in HBASE-10018 we removed such logic along with 
> region-location-prefetching. 
> We regard this as an unexpected behavior change and observed below phenomenon 
> in our product env:
> 1. Unnecessary connection setup to meta when multiple threads locating region 
> in a client process
> 2. Priority handler of the RS holding meta region exhausted, application keep 
> retrying and cause a vicious circle
> To resolve this problem, we propose to add the {{userRegionLock}} back and 
> keep the behavior in accordance with 0.98



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-15320) HBase connector for Kafka Connect

[Mike Wingert (JIRA)]

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

Mike Wingert updated HBASE-15320:
-
Attachment: HBASE-15320.master.4.patch

> HBase connector for Kafka Connect
> -
>
> Key: HBASE-15320
> URL: https://issues.apache.org/jira/browse/HBASE-15320
> Project: HBase
>  Issue Type: New Feature
>  Components: Replication
>Reporter: Andrew Purtell
>Assignee: Mike Wingert
>  Labels: beginner
> Fix For: 3.0.0
>
> Attachments: HBASE-15320.master.1.patch, HBASE-15320.master.2.patch, 
> HBASE-15320.master.3.patch, HBASE-15320.master.4.patch
>
>
> Implement an HBase connector with source and sink tasks for the Connect 
> framework (http://docs.confluent.io/2.0.0/connect/index.html) available in 
> Kafka 0.9 and later.
> See also: 
> http://www.confluent.io/blog/announcing-kafka-connect-building-large-scale-low-latency-data-pipelines
> An HBase source 
> (http://docs.confluent.io/2.0.0/connect/devguide.html#task-example-source-task)
>  could be implemented as a replication endpoint or WALObserver, publishing 
> cluster wide change streams from the WAL to one or more topics, with 
> configurable mapping and partitioning of table changes to topics.  
> An HBase sink task 
> (http://docs.confluent.io/2.0.0/connect/devguide.html#sink-tasks) would 
> persist, with optional transformation (JSON? Avro?, map fields to native 
> schema?), Kafka SinkRecords into HBase tables.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (HBASE-19260) Add lock back to avoid parallel accessing meta to locate region

[Yu Li (JIRA)]

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

Yu Li reassigned HBASE-19260:
-

Assignee: Yu Li

> Add lock back to avoid parallel accessing meta to locate region
> ---
>
> Key: HBASE-19260
> URL: https://issues.apache.org/jira/browse/HBASE-19260
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.3.1, 1.2.6, 2.0.0-alpha-3, 1.1.12
>Reporter: Yu Li
>Assignee: Yu Li
>
> In branch-0.98 we have below codes to avoid accessing meta in parallel in 
> {{HConnectionManager}}:
> {code}
>   Result regionInfoRow;
>   // This block guards against two threads trying to load the meta
>   // region at the same time. The first will load the meta region and
>   // the second will use the value that the first one found.
>   if (useCache) {
> if (TableName.META_TABLE_NAME.equals(parentTable) && usePrefetch 
> &&
> getRegionCachePrefetch(tableName)) {
>   synchronized (regionLockObject) {
> // Check the cache again for a hit in case some other thread 
> made the
> // same query while we were waiting on the lock.
> ...
>   }
> }
>   ...
> {code}
> while in HBASE-10018 we removed such logic along with 
> region-location-prefetching. 
> We regard this as an unexpected behavior change and observed below phenomenon 
> in our product env:
> 1. Unnecessary connection setup to meta when multiple threads locating region 
> in a client process
> 2. Priority handler of the RS holding meta region exhausted, application keep 
> retrying and cause a vicious circle
> To resolve this problem, we propose to add the {{userRegionLock}} back and 
> keep the behavior in accordance with 0.98



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19260) Add lock back to avoid parallel accessing meta to locate region

[Yu Li (JIRA)]

Yu Li created HBASE-19260:
-

 Summary: Add lock back to avoid parallel accessing meta to locate 
region
 Key: HBASE-19260
 URL: https://issues.apache.org/jira/browse/HBASE-19260
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.1.12, 2.0.0-alpha-3, 1.2.6, 1.3.1
Reporter: Yu Li


In branch-0.98 we have below codes to avoid accessing meta in parallel in 
{{HConnectionManager}}:
{code}
  Result regionInfoRow;
  // This block guards against two threads trying to load the meta
  // region at the same time. The first will load the meta region and
  // the second will use the value that the first one found.
  if (useCache) {
if (TableName.META_TABLE_NAME.equals(parentTable) && usePrefetch &&
getRegionCachePrefetch(tableName)) {
  synchronized (regionLockObject) {
// Check the cache again for a hit in case some other thread 
made the
// same query while we were waiting on the lock.
...
  }
}
  ...
{code}
while in HBASE-10018 we removed such logic along with 
region-location-prefetching. 

We regard this as an unexpected behavior change and observed below phenomenon 
in our product env:
1. Unnecessary connection setup to meta when multiple threads locating region 
in a client process
2. Priority handler of the RS holding meta region exhausted, application keep 
retrying and cause a vicious circle

To resolve this problem, we propose to add the {{userRegionLock}} back and keep 
the behavior in accordance with 0.98



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18963) Remove MultiRowMutationProcessor and implement mutateRows... methods using batchMutate()

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-18963:
---

| (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:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  0m  
0s{color} | {color:blue} Findbugs executables are not available. {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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
 4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
41s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
26s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
 9s{color} | {color:green} hbase-server: The patch generated 0 new + 346 
unchanged - 8 fixed = 346 total (was 354) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
37s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
51m 37s{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 2.7.4 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
33s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}105m 
47s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
18s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}176m  3s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-18963 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12897642/hbase-18963.master.005.patch
 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 2503c9319126 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19 
15:49:21 UTC 2017 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 / f9b19c6e33 |
| maven | version: Apache Maven 3.5.2 
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9806/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9806/console |
| Powered by | Apache Yetus 0.6.0   http://yetus.apache.org |


This message was 

[jira] [Updated] (HBASE-15320) HBase connector for Kafka Connect

[Mike Wingert (JIRA)]

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

Mike Wingert updated HBASE-15320:
-
Attachment: HBASE-15320.master.3.patch

> HBase connector for Kafka Connect
> -
>
> Key: HBASE-15320
> URL: https://issues.apache.org/jira/browse/HBASE-15320
> Project: HBase
>  Issue Type: New Feature
>  Components: Replication
>Reporter: Andrew Purtell
>Assignee: Mike Wingert
>  Labels: beginner
> Fix For: 3.0.0
>
> Attachments: HBASE-15320.master.1.patch, HBASE-15320.master.2.patch, 
> HBASE-15320.master.3.patch
>
>
> Implement an HBase connector with source and sink tasks for the Connect 
> framework (http://docs.confluent.io/2.0.0/connect/index.html) available in 
> Kafka 0.9 and later.
> See also: 
> http://www.confluent.io/blog/announcing-kafka-connect-building-large-scale-low-latency-data-pipelines
> An HBase source 
> (http://docs.confluent.io/2.0.0/connect/devguide.html#task-example-source-task)
>  could be implemented as a replication endpoint or WALObserver, publishing 
> cluster wide change streams from the WAL to one or more topics, with 
> configurable mapping and partitioning of table changes to topics.  
> An HBase sink task 
> (http://docs.confluent.io/2.0.0/connect/devguide.html#sink-tasks) would 
> persist, with optional transformation (JSON? Avro?, map fields to native 
> schema?), Kafka SinkRecords into HBase tables.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19146) Hbase3.0 protobuf-maven-plugin do not support Arm64(only for x86)

[Yuqi Gu (JIRA)]

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

Yuqi Gu updated HBASE-19146:

Description: 
We are building the HBase 3.0.0-SNAPSHOT on AARCH64.
It is noted that 'protobuf-maven-plugin' only support x86 shown as follows:

{code:java}
 
   org.xolstice.maven.plugins
   protobuf-maven-plugin
   ${protobuf.plugin.version}
   
  com.google.protobuf:protoc:${external.protobuf.version}:
exe:${os.detected.classifier}



com.google.protobuf:protoc:${external.protobuf.version}:exe:${os.detected.classifier}


   false
   true
  


{code}

So the build is failed.

{code:java}
[INFO] --- protobuf-maven-plugin:0.5.0:compile (compile-protoc) @ 
hbase-protocol-shaded ---
[INFO] Compiling 32 proto file(s) to 
/root/hbase/hbase-protocol-shaded/target/generated-sources/protobuf/java
Failed to execute goal 
org.xolstice.maven.plugins:protobuf-maven-plugin:0.5.0:compile (compile-protoc) 
on project hbase-protocol-shaded: Missing:
{code}


Then I installed aarch64 protobuf 2.5.0 on the host and modify the pom:

{code:java}
-   
com.google.protobuf:protoc:${external.protobuf.version}:exe:${os.detected.classifier}
+  /usr/local/bin/protoc

{code}
 The build is also failed:

{code:java}
[INFO] Compiling 32 proto file(s) to 
/root/hbase/hbase-protocol-shaded/target/generated-sources/protobuf/java
[ERROR] PROTOC FAILED: google/protobuf/any.proto:31:10: Unrecognized syntax 
identifier "proto3".  This parser only recognizes "proto2".

{code}

It seems that "internal.protobuf.version" in "hbase-protocol-shaded" is 3.3.0.

How to fix it? Thanks!

  


  was:
We are building the HBase 3.0.0-SNAPSHOT on AARCH64.
It is noted that 'protobuf-maven-plugin' only support x86 shown as follows:

{code:java}
 
   org.xolstice.maven.plugins
   protobuf-maven-plugin
   ${protobuf.plugin.version}
   
  com.google.protobuf:protoc:${external.protobuf.version}:
exe:${os.detected.classifier}



com.google.protobuf:protoc:${external.protobuf.version}:exe:${os.detected.classifier}


   false
   true
  


{code}

So the build is failed.

{code:java}
[INFO] --- protobuf-maven-plugin:0.5.0:compile (compile-protoc) @ 
hbase-protocol-shaded ---
[INFO] Compiling 32 proto file(s) to 
/root/hbase/hbase-protocol-shaded/target/generated-sources/protobuf/java
Failed to execute goal 
org.xolstice.maven.plugins:protobuf-maven-plugin:0.5.0:compile (compile-protoc) 
on project hbase-protocol-shaded: Missing:
{code}


Then I installed aarch64 protobuf 2.5.0 on the host and modify the pom:

{code:java}
-   ${basedir}/src/main/protobuf/
+  /usr/local/bin/protoc

{code}
 The build is also failed:

{code:java}
[INFO] Compiling 32 proto file(s) to 
/root/hbase/hbase-protocol-shaded/target/generated-sources/protobuf/java
[ERROR] PROTOC FAILED: google/protobuf/any.proto:31:10: Unrecognized syntax 
identifier "proto3".  This parser only recognizes "proto2".

{code}

It seems that "internal.protobuf.version" in "hbase-protocol-shaded" is 3.3.0.

How to fix it? Thanks!

  



> Hbase3.0  protobuf-maven-plugin do not support Arm64(only for x86)
> --
>
> Key: HBASE-19146
> URL: https://issues.apache.org/jira/browse/HBASE-19146
> Project: HBase
>  Issue Type: Bug
>  Components: build, pom
>Affects Versions: 3.0.0
> Environment: OS:  Ubuntu 16.04.3 
> OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.16.04.3-b11)
> Hw platform:  AARCH64
>Reporter: Yuqi Gu
>
> We are building the HBase 3.0.0-SNAPSHOT on AARCH64.
> It is noted that 'protobuf-maven-plugin' only support x86 shown as follows:
> {code:java}
>  
>org.xolstice.maven.plugins
>protobuf-maven-plugin
>${protobuf.plugin.version}
>
>   com.google.protobuf:protoc:${external.protobuf.version}:
> exe:${os.detected.classifier}
> 
> com.google.protobuf:protoc:${external.protobuf.version}:exe:${os.detected.classifier}
> 
>false
>true
>   
> 
> {code}
> So the build is failed.
> {code:java}
> [INFO] --- protobuf-maven-plugin:0.5.0:compile (compile-protoc) @ 
> hbase-protocol-shaded ---
> [INFO] Compiling 32 proto file(s) to 
> /root/hbase/hbase-protocol-shaded/target/generated-sources/protobuf/java
> Failed to execute goal 
> org.xolstice.maven.plugins:protobuf-maven-plugin:0.5.0:compile 
> (compile-protoc) on project hbase-protocol-shaded: Missing:
> {code}
> Then I installed aarch64 protobuf 2.5.0 on the host and modify the pom:
> {code:java}
> -   
> com.google.protobuf:protoc:${external.protobuf.version}:exe:${os.detected.classifier}
> +  /usr/local/bin/protoc
> {code}
>  The build is also failed:
> {code:java}
> [INFO] Compiling 32 proto file(s) to 
> 

[jira] [Commented] (HBASE-12091) Optionally ignore edits for dropped tables for replication.

[Hudson (JIRA)]

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

Hudson commented on HBASE-12091:


FAILURE: Integrated in Jenkins build HBase-2.0 #853 (See 
[https://builds.apache.org/job/HBase-2.0/853/])
HBASE-12091 Optionally ignore edits for dropped tables for replication. (larsh: 
rev 3d4fd90947105d47d5c35d5a37f36cc56b9705de)
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSink.java
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/protobuf/ReplicationProtbufUtil.java
* (add) 
hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationDroppedTables.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/HBaseInterClusterReplicationEndpoint.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/ReplicationEndpoint.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceManager.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/RetriesExhaustedWithDetailsException.java


> Optionally ignore edits for dropped tables for replication.
> ---
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 2.0.0, 3.0.0, 1.4.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt, 
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt, 
> 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, 
> 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091-v9-branch-1.txt, 
> 12091-v9-master.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and 
> the sink, but the source still has outstanding edits that now it could not 
> get rid of. Now all replication is backed up behind these unreplicatable 
> edits.
> We should have an option to ignore edits for tables dropped at the source.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-15320) HBase connector for Kafka Connect

[Mike Wingert (JIRA)]

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

Mike Wingert commented on HBASE-15320:
--

Hi Ted,

That was the version of the broker I was testing with.  I will bump it once I 
get my new test environment set up.

> HBase connector for Kafka Connect
> -
>
> Key: HBASE-15320
> URL: https://issues.apache.org/jira/browse/HBASE-15320
> Project: HBase
>  Issue Type: New Feature
>  Components: Replication
>Reporter: Andrew Purtell
>Assignee: Mike Wingert
>  Labels: beginner
> Fix For: 3.0.0
>
> Attachments: HBASE-15320.master.1.patch, HBASE-15320.master.2.patch
>
>
> Implement an HBase connector with source and sink tasks for the Connect 
> framework (http://docs.confluent.io/2.0.0/connect/index.html) available in 
> Kafka 0.9 and later.
> See also: 
> http://www.confluent.io/blog/announcing-kafka-connect-building-large-scale-low-latency-data-pipelines
> An HBase source 
> (http://docs.confluent.io/2.0.0/connect/devguide.html#task-example-source-task)
>  could be implemented as a replication endpoint or WALObserver, publishing 
> cluster wide change streams from the WAL to one or more topics, with 
> configurable mapping and partitioning of table changes to topics.  
> An HBase sink task 
> (http://docs.confluent.io/2.0.0/connect/devguide.html#sink-tasks) would 
> persist, with optional transformation (JSON? Avro?, map fields to native 
> schema?), Kafka SinkRecords into HBase tables.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-12091) Optionally ignore edits for dropped tables for replication.

[Hudson (JIRA)]

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

Hudson commented on HBASE-12091:


FAILURE: Integrated in Jenkins build HBase-1.4 #1017 (See 
[https://builds.apache.org/job/HBase-1.4/1017/])
HBASE-12091 Optionally ignore edits for dropped tables for replication. 
(apurtell: rev b93a80596dfc01b67a3b1561ef49f4b4c7eb900b)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSink.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/RetriesExhaustedWithDetailsException.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/protobuf/ReplicationProtbufUtil.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/HBaseInterClusterReplicationEndpoint.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceManager.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/ReplicationEndpoint.java
* (add) 
hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationDroppedTables.java


> Optionally ignore edits for dropped tables for replication.
> ---
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 2.0.0, 3.0.0, 1.4.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt, 
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt, 
> 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, 
> 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091-v9-branch-1.txt, 
> 12091-v9-master.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and 
> the sink, but the source still has outstanding edits that now it could not 
> get rid of. Now all replication is backed up behind these unreplicatable 
> edits.
> We should have an option to ignore edits for tables dropped at the source.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-12091) Optionally ignore edits for dropped tables for replication.

[Andrew Purtell (JIRA)]

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

Andrew Purtell updated HBASE-12091:
---
Fix Version/s: (was: 1.5.0)
   1.4.0

I brought this in to 1.4. We can kick it out if it presents a problem during 
testing of the RC

> Optionally ignore edits for dropped tables for replication.
> ---
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 2.0.0, 3.0.0, 1.4.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt, 
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt, 
> 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, 
> 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091-v9-branch-1.txt, 
> 12091-v9-master.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and 
> the sink, but the source still has outstanding edits that now it could not 
> get rid of. Now all replication is backed up behind these unreplicatable 
> edits.
> We should have an option to ignore edits for tables dropped at the source.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19114) Split out o.a.h.h.zookeeper from hbase-server and hbase-client

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-19114:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
12s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue}  0m  
5s{color} | {color:blue} Shelldocs was not available. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  0m  
0s{color} | {color:blue} Findbugs executables are not available. {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 78 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
13s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  5m 
 9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  9m 
11s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  6m 
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
 1s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  5m 
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {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}  5m 
 2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  8m 
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  8m 
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
29s{color} | {color:green} hbase-client: The patch generated 0 new + 0 
unchanged - 200 fixed = 0 total (was 200) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  0m 
15s{color} | {color:red} hbase-zookeeper: The patch generated 241 new + 0 
unchanged - 0 fixed = 241 total (was 0) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  2m 
46s{color} | {color:red} root: The patch generated 275 new + 1529 unchanged - 
284 fixed = 1804 total (was 1813) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
11s{color} | {color:green} The patch hbase-client-project passed checkstyle 
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
10s{color} | {color:green} The patch hbase-shaded-client-project passed 
checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
10s{color} | {color:green} The patch hbase-assembly passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
22s{color} | {color:green} The patch hbase-it passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
18s{color} | {color:green} The patch hbase-mapreduce passed checkstyle {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  0m 
11s{color} | {color:red} hbase-replication: The patch generated 4 new + 30 
unchanged - 5 fixed = 34 total (was 35) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
12s{color} | {color:green} The patch hbase-rsgroup passed checkstyle {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  1m 
31s{color} | {color:red} hbase-server: The patch generated 30 new + 1465 
unchanged - 79 fixed = 1495 total (was 1544) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
11s{color} | {color:green} The patch hbase-shell passed checkstyle {color} |
| {color:green}+1{color} | {color:green} rubocop 

[jira] [Updated] (HBASE-18090) Improve TableSnapshotInputFormat to allow more multiple mappers per region

[xinxin fan (JIRA)]

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

xinxin fan updated HBASE-18090:
---
Attachment: (was: HBASE-18090-branch-1-v2.patch)

> Improve TableSnapshotInputFormat to allow more multiple mappers per region
> --
>
> Key: HBASE-18090
> URL: https://issues.apache.org/jira/browse/HBASE-18090
> Project: HBase
>  Issue Type: Improvement
>  Components: mapreduce
>Reporter: Mikhail Antonov
>Assignee: xinxin fan
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18090-V3-master.patch, 
> HBASE-18090-V4-master.patch, HBASE-18090-V5-master.patch, 
> HBASE-18090-branch-1-v2.patch, HBASE-18090-branch-1.3-v1.patch, 
> HBASE-18090-branch-1.3-v2.patch, HBASE-18090.branch-1.patch
>
>
> TableSnapshotInputFormat runs one map task per region in the table snapshot. 
> This places unnecessary restriction that the region layout of the original 
> table needs to take the processing resources available to MR job into 
> consideration. Allowing to run multiple mappers per region (assuming 
> reasonably even key distribution) would be useful.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18090) Improve TableSnapshotInputFormat to allow more multiple mappers per region

[xinxin fan (JIRA)]

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

xinxin fan updated HBASE-18090:
---
Attachment: HBASE-18090-branch-1-v2.patch

> Improve TableSnapshotInputFormat to allow more multiple mappers per region
> --
>
> Key: HBASE-18090
> URL: https://issues.apache.org/jira/browse/HBASE-18090
> Project: HBase
>  Issue Type: Improvement
>  Components: mapreduce
>Reporter: Mikhail Antonov
>Assignee: xinxin fan
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18090-V3-master.patch, 
> HBASE-18090-V4-master.patch, HBASE-18090-V5-master.patch, 
> HBASE-18090-branch-1-v2.patch, HBASE-18090-branch-1.3-v1.patch, 
> HBASE-18090-branch-1.3-v2.patch, HBASE-18090.branch-1.patch
>
>
> TableSnapshotInputFormat runs one map task per region in the table snapshot. 
> This places unnecessary restriction that the region layout of the original 
> table needs to take the processing resources available to MR job into 
> consideration. Allowing to run multiple mappers per region (assuming 
> reasonably even key distribution) would be useful.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18090) Improve TableSnapshotInputFormat to allow more multiple mappers per region

[xinxin fan (JIRA)]

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

xinxin fan commented on HBASE-18090:


I have tried serveral times these days, it seems build timed out. 
https://builds.apache.org/job/PreCommit-HBASE-Build/9799/console. 

> Improve TableSnapshotInputFormat to allow more multiple mappers per region
> --
>
> Key: HBASE-18090
> URL: https://issues.apache.org/jira/browse/HBASE-18090
> Project: HBase
>  Issue Type: Improvement
>  Components: mapreduce
>Reporter: Mikhail Antonov
>Assignee: xinxin fan
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18090-V3-master.patch, 
> HBASE-18090-V4-master.patch, HBASE-18090-V5-master.patch, 
> HBASE-18090-branch-1-v2.patch, HBASE-18090-branch-1.3-v1.patch, 
> HBASE-18090-branch-1.3-v2.patch, HBASE-18090.branch-1.patch
>
>
> TableSnapshotInputFormat runs one map task per region in the table snapshot. 
> This places unnecessary restriction that the region layout of the original 
> table needs to take the processing resources available to MR job into 
> consideration. Allowing to run multiple mappers per region (assuming 
> reasonably even key distribution) would be useful.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-15320) HBase connector for Kafka Connect

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-15320:
---

| (x) *{color:red}-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:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue}  0m  
4s{color} | {color:blue} Shelldocs was not available. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  0m  
0s{color} | {color:blue} Findbugs executables are not available. {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:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
12s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  4m 
56s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  2m 
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
34s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  3m 
22s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {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}  4m 
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  5m 
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  5m 
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  2m 
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green}  0m 
 1s{color} | {color:green} There were no new shellcheck issues. {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red}  0m  
0s{color} | {color:red} The patch has 4 line(s) that end in whitespace. Use git 
apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply 
{color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green}  0m  
6s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
35s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
53m  0s{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 2.7.4 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  3m 
16s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}165m 20s{color} 
| {color:red} root 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}255m 41s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | 
hadoop.hbase.org.apache.hadoop.hbase.kafka.TestProxyRegionServer |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-15320 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12897630/HBASE-15320.master.2.patch
 |
| Optional Tests |  asflicense  shellcheck  shelldocs  javac  javadoc  unit  
shadedjars  hadoopcheck  xml  compile  findbugs  hbaseanti  checkstyle 

[jira] [Updated] (HBASE-12091) Optionally ignore edits for dropped tables for replication.

[Lars Hofhansl (JIRA)]

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

Lars Hofhansl updated HBASE-12091:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Optionally ignore edits for dropped tables for replication.
> ---
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 2.0.0, 3.0.0, 1.5.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt, 
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt, 
> 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, 
> 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091-v9-branch-1.txt, 
> 12091-v9-master.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and 
> the sink, but the source still has outstanding edits that now it could not 
> get rid of. Now all replication is backed up behind these unreplicatable 
> edits.
> We should have an option to ignore edits for tables dropped at the source.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-12091) Optionally ignore edits for dropped tables for replication.

[Lars Hofhansl (JIRA)]

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

Lars Hofhansl edited comment on HBASE-12091 at 11/15/17 1:17 AM:
-

What I committed to master and branch-2.


was (Author: lhofhansl):
What I committed to master

> Optionally ignore edits for dropped tables for replication.
> ---
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 2.0.0, 3.0.0, 1.5.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt, 
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt, 
> 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, 
> 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091-v9-branch-1.txt, 
> 12091-v9-master.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and 
> the sink, but the source still has outstanding edits that now it could not 
> get rid of. Now all replication is backed up behind these unreplicatable 
> edits.
> We should have an option to ignore edits for tables dropped at the source.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-12091) Optionally ignore edits for dropped tables for replication.

[Lars Hofhansl (JIRA)]

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

Lars Hofhansl commented on HBASE-12091:
---

e can decide on a backport to earlier branches.

> Optionally ignore edits for dropped tables for replication.
> ---
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 2.0.0, 3.0.0, 1.5.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt, 
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt, 
> 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, 
> 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091-v9-branch-1.txt, 
> 12091-v9-master.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and 
> the sink, but the source still has outstanding edits that now it could not 
> get rid of. Now all replication is backed up behind these unreplicatable 
> edits.
> We should have an option to ignore edits for tables dropped at the source.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-12091) Optionally ignore edits for dropped tables for replication.

[Lars Hofhansl (JIRA)]

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

Lars Hofhansl edited comment on HBASE-12091 at 11/15/17 1:17 AM:
-

We can decide on a backport to earlier branches.


was (Author: lhofhansl):
e can decide on a backport to earlier branches.

> Optionally ignore edits for dropped tables for replication.
> ---
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 2.0.0, 3.0.0, 1.5.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt, 
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt, 
> 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, 
> 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091-v9-branch-1.txt, 
> 12091-v9-master.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and 
> the sink, but the source still has outstanding edits that now it could not 
> get rid of. Now all replication is backed up behind these unreplicatable 
> edits.
> We should have an option to ignore edits for tables dropped at the source.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-12091) Optionally ignore edits for dropped tables for replication.

[Lars Hofhansl (JIRA)]

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

Lars Hofhansl updated HBASE-12091:
--
Fix Version/s: (was: 1.4.1)

> Optionally ignore edits for dropped tables for replication.
> ---
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 2.0.0, 3.0.0, 1.5.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt, 
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt, 
> 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, 
> 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091-v9-branch-1.txt, 
> 12091-v9-master.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and 
> the sink, but the source still has outstanding edits that now it could not 
> get rid of. Now all replication is backed up behind these unreplicatable 
> edits.
> We should have an option to ignore edits for tables dropped at the source.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-12091) Optionally ignore edits for dropped tables for replication.

[Lars Hofhansl (JIRA)]

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

Lars Hofhansl updated HBASE-12091:
--
Attachment: 12091-v9-master.txt

What I committed to master

> Optionally ignore edits for dropped tables for replication.
> ---
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 2.0.0, 3.0.0, 1.4.1, 1.5.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt, 
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt, 
> 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, 
> 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091-v9-branch-1.txt, 
> 12091-v9-master.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and 
> the sink, but the source still has outstanding edits that now it could not 
> get rid of. Now all replication is backed up behind these unreplicatable 
> edits.
> We should have an option to ignore edits for tables dropped at the source.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-12091) Optionally ignore edits for dropped tables for replication.

[Lars Hofhansl (JIRA)]

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

Lars Hofhansl updated HBASE-12091:
--
Attachment: 12091-v9-branch-1.txt

What I committed to branch-1

> Optionally ignore edits for dropped tables for replication.
> ---
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 2.0.0, 3.0.0, 1.4.1, 1.5.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt, 
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt, 
> 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, 
> 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091-v9-branch-1.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and 
> the sink, but the source still has outstanding edits that now it could not 
> get rid of. Now all replication is backed up behind these unreplicatable 
> edits.
> We should have an option to ignore edits for tables dropped at the source.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-12091) Optionally ignore edits for dropped tables for replication.

[Hudson (JIRA)]

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

Hudson commented on HBASE-12091:


FAILURE: Integrated in Jenkins build HBase-1.5 #158 (See 
[https://builds.apache.org/job/HBase-1.5/158/])
HBASE-12091 Optionally ignore edits for dropped tables for replication. (larsh: 
rev f9833a7802bd0d4291e8b6ec6baf2f85fe2e401f)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/protobuf/ReplicationProtbufUtil.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceManager.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/RetriesExhaustedWithDetailsException.java
* (add) 
hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationDroppedTables.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/HBaseInterClusterReplicationEndpoint.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/ReplicationEndpoint.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSink.java


> Optionally ignore edits for dropped tables for replication.
> ---
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 2.0.0, 3.0.0, 1.4.1, 1.5.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt, 
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt, 
> 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, 
> 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and 
> the sink, but the source still has outstanding edits that now it could not 
> get rid of. Now all replication is backed up behind these unreplicatable 
> edits.
> We should have an option to ignore edits for tables dropped at the source.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-15320) HBase connector for Kafka Connect

[Ted Yu (JIRA)]

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

Ted Yu commented on HBASE-15320:


Can you put patch on review board ?
{code}
150   kafka-clients
151   0.9.0.1
{code}
Why not use 1.0.0 release ?

> HBase connector for Kafka Connect
> -
>
> Key: HBASE-15320
> URL: https://issues.apache.org/jira/browse/HBASE-15320
> Project: HBase
>  Issue Type: New Feature
>  Components: Replication
>Reporter: Andrew Purtell
>Assignee: Mike Wingert
>  Labels: beginner
> Fix For: 3.0.0
>
> Attachments: HBASE-15320.master.1.patch, HBASE-15320.master.2.patch
>
>
> Implement an HBase connector with source and sink tasks for the Connect 
> framework (http://docs.confluent.io/2.0.0/connect/index.html) available in 
> Kafka 0.9 and later.
> See also: 
> http://www.confluent.io/blog/announcing-kafka-connect-building-large-scale-low-latency-data-pipelines
> An HBase source 
> (http://docs.confluent.io/2.0.0/connect/devguide.html#task-example-source-task)
>  could be implemented as a replication endpoint or WALObserver, publishing 
> cluster wide change streams from the WAL to one or more topics, with 
> configurable mapping and partitioning of table changes to topics.  
> An HBase sink task 
> (http://docs.confluent.io/2.0.0/connect/devguide.html#sink-tasks) would 
> persist, with optional transformation (JSON? Avro?, map fields to native 
> schema?), Kafka SinkRecords into HBase tables.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19245) MultiTableInputFormatBase#getSplits creates a Connection per Table

[Ted Yu (JIRA)]

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

Ted Yu commented on HBASE-19245:


+1
Please address findbugs warning.

> MultiTableInputFormatBase#getSplits creates a Connection per Table
> --
>
> Key: HBASE-19245
> URL: https://issues.apache.org/jira/browse/HBASE-19245
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Reporter: stack
>Assignee: stack
>Priority: Minor
> Attachments: HBASE-19245.branch-2.001.patch, 
> HBASE-19245.branch-2.002.patch, HBASE-19245.branch-2.003.patch, 
> HBASE-19245.branch-2.004.patch
>
>
> Doesn't have to. Connection setup costs. Shared Connection could save on 
> hbase:meta hits (perhaps).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19259) Explore if mutations can be sorted by rows for mutateRows() method

[Umesh Agashe (JIRA)]

Umesh Agashe created HBASE-19259:


 Summary: Explore if mutations can be sorted by rows for 
mutateRows() method
 Key: HBASE-19259
 URL: https://issues.apache.org/jira/browse/HBASE-19259
 Project: HBase
  Issue Type: Improvement
  Components: regionserver
Affects Versions: 2.0.0-alpha-4
Reporter: Umesh Agashe
Assignee: Umesh Agashe
 Fix For: 3.0.0


For non atomic batch operations mutations are sorted by rows. Explore if 
mutations can be sorted by rows for mutateRows() method.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18978) Align the methods in Table and AsyncTable

[Duo Zhang (JIRA)]

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

Duo Zhang commented on HBASE-18978:
---

Have you looked at HBASE-19251? Where I tried to merge the two interfaces.

And, what is an async scan?

> Align the methods in Table and AsyncTable
> -
>
> Key: HBASE-18978
> URL: https://issues.apache.org/jira/browse/HBASE-18978
> Project: HBase
>  Issue Type: Task
>  Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Peter Somogyi
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18978) Align the methods in Table and AsyncTable

[Appy (JIRA)]

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

Appy commented on HBASE-18978:
--

Yup, they looked totally different,
- one seemed like, get all result and use consumer to process them, in async way
- other one is more like, streaming results and processing simultaneously, with 
ability to stop-start scan on will.

But that feature seems orthogonal/unrelated to semantics of separate/same 
threadpool. So i couldn't understand why can't we mix and match. For eg. why 
can't one do 'streaming scan' ('raw' is overloaded) with common threadpool 
(just like other power user thing, right?) or why can't one do simple async 
scan with separate threadpool?

> Align the methods in Table and AsyncTable
> -
>
> Key: HBASE-18978
> URL: https://issues.apache.org/jira/browse/HBASE-18978
> Project: HBase
>  Issue Type: Task
>  Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Peter Somogyi
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-19255) PerformanceEvaluation class not found when run PE test

[Appy (JIRA)]

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

Appy edited comment on HBASE-19255 at 11/15/17 12:00 AM:
-

I think current way is better - most MR dependent tools are in hbase-mapreduce 
now.
+1 on 001.patch.


was (Author: appy):
I think current way is better.
+1 on 001.patch.

> PerformanceEvaluation class not found when run PE test
> --
>
> Key: HBASE-19255
> URL: https://issues.apache.org/jira/browse/HBASE-19255
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 3.0.0, 2.0.0-beta-1
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 3.0.0, 2.0.0-beta-1
>
> Attachments: HBASE-19255.master.001.patch
>
>
> {code}
> mvn clean package install -DskipTests
> ./hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=1 --nomapred 
> randomWrite 1
> {code}
> PerformanceEvaluation is in hbase-mapreduce module's test jar. After 
> HBASE-18640, we move mapreduce out of hbase-server into separate 
> hbase-mapreduce module. But didn't add the hbase-mapreduce test jar to 
> hbase-assembly pom.xml. So it didn't add to the default classpath. Then the 
> PerformanceEvaluation can't found.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19255) PerformanceEvaluation class not found when run PE test

[Appy (JIRA)]

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

Appy commented on HBASE-19255:
--

I think current way is better.
+1 on 001.patch.

> PerformanceEvaluation class not found when run PE test
> --
>
> Key: HBASE-19255
> URL: https://issues.apache.org/jira/browse/HBASE-19255
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 3.0.0, 2.0.0-beta-1
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 3.0.0, 2.0.0-beta-1
>
> Attachments: HBASE-19255.master.001.patch
>
>
> {code}
> mvn clean package install -DskipTests
> ./hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=1 --nomapred 
> randomWrite 1
> {code}
> PerformanceEvaluation is in hbase-mapreduce module's test jar. After 
> HBASE-18640, we move mapreduce out of hbase-server into separate 
> hbase-mapreduce module. But didn't add the hbase-mapreduce test jar to 
> hbase-assembly pom.xml. So it didn't add to the default classpath. Then the 
> PerformanceEvaluation can't found.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18978) Align the methods in Table and AsyncTable

[Duo Zhang (JIRA)]

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

Duo Zhang commented on HBASE-18978:
---

Totally different, not only a thread pool... Have you looked at the two 
ScanResultComsumer? They’re totally different.

> Align the methods in Table and AsyncTable
> -
>
> Key: HBASE-18978
> URL: https://issues.apache.org/jira/browse/HBASE-18978
> Project: HBase
>  Issue Type: Task
>  Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Peter Somogyi
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19235) CoprocessorEnvironment should be exposed to CPs

[Appy (JIRA)]

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

Appy commented on HBASE-19235:
--

Seems to be turning into bikeshed. I am fine with latest v3 mainly because I 
think it's probably better to have bad code internally than have users deal 
with the confusion (if those are the only two options).

> CoprocessorEnvironment should be exposed to CPs
> ---
>
> Key: HBASE-19235
> URL: https://issues.apache.org/jira/browse/HBASE-19235
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Affects Versions: 2.0.0-alpha-4
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Minor
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19235.patch, HBASE-19235_V2.patch, 
> HBASE-19235_V3.patch, HBASE-19235_V3.patch
>
>
> Its sub interfaces are exposed with 
> LimitedPrivate(HBaseInterfaceAudience.COPROC).  So ideally all the functions 
> in this are.  Better we mark CoprocessorEnvironment also as CP exposed to 
> avoid confusion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18978) Align the methods in Table and AsyncTable

[Appy (JIRA)]

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

Appy commented on HBASE-18978:
--

Can someone want to use a non-raw asynctable but raw scanner? Can give a 
threadpool just for the scanner right?
Unlessthe difference between raw scanner and non-raw scanner in this case 
is not about threadpool.


> Align the methods in Table and AsyncTable
> -
>
> Key: HBASE-18978
> URL: https://issues.apache.org/jira/browse/HBASE-18978
> Project: HBase
>  Issue Type: Task
>  Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Peter Somogyi
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-19114) Split out o.a.h.h.zookeeper from hbase-server and hbase-client

[Appy (JIRA)]

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

Appy edited comment on HBASE-19114 at 11/14/17 11:47 PM:
-

Coming back here after our discussion on HBASE-19200.
hbase-client doesn't depend on hbase-zookeeper anymore, it's vice versa.
Uploaded new patch on a new review board.  https://reviews.apache.org/r/63820/ 
(link label above: Review Board (master))

[~stack] [~Apache9] what do you think?


was (Author: appy):
Coming back here after our discussion on HBASE-19200.
hbase-client doesn't depend on hbase-zookeeper anymore, it's vice versa.
Uploaded new patch on a new review board.  https://reviews.apache.org/r/63820/ 
(link label above: Review Board (master))

> Split out o.a.h.h.zookeeper from hbase-server and hbase-client
> --
>
> Key: HBASE-19114
> URL: https://issues.apache.org/jira/browse/HBASE-19114
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19114.master.001.patch, 
> HBASE-19114.master.002.patch, HBASE-19114.master.003.patch, 
> HBASE-19114.master.004.patch, HBASE-19114.master.005.patch, 
> HBASE-19114.master.006.patch
>
>
> Changes so far:
> - Moved DrainingServerTracker and RegionServerTracker to 
> hbase-server:o.a.h.h.master.
> - Moved SplitOrMergeTracker to oahh.master (because it depends on a PB)
> - Moving hbase-client:oahh.zookeeper.*  to hbase-zookeeper module.  After 
> [~Apache9]'s cleanup (HBASE-19200), hbase-client doesn't need them anymore 
> (except 3 classes).
> - Renamed some classes to use a consistent naming for classes - ZK instead of 
> mix of ZK, Zk , ZooKeeper. Couldn't rename following public classes: 
> MiniZooKeeperCluster, ZooKeeperConnectionException. Left RecoverableZooKeeper 
> for lack of better name. (suggestions?)
> - Sadly, can't move tests out because they depend on HBaseTestingUtility 
> (which defeats part of the purpose - trimming down hbase-server tests. We 
> need to promote more use of mocks in our tests)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19114) Split out o.a.h.h.zookeeper from hbase-server and hbase-client

[Appy (JIRA)]

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

Appy commented on HBASE-19114:
--

Coming back here after our discussion on HBASE-19200.
hbase-client doesn't depend on hbase-zookeeper anymore, it's vice versa.
Uploaded new patch on a new review board.  https://reviews.apache.org/r/63820/ 
(link label above: Review Board (master))

> Split out o.a.h.h.zookeeper from hbase-server and hbase-client
> --
>
> Key: HBASE-19114
> URL: https://issues.apache.org/jira/browse/HBASE-19114
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19114.master.001.patch, 
> HBASE-19114.master.002.patch, HBASE-19114.master.003.patch, 
> HBASE-19114.master.004.patch, HBASE-19114.master.005.patch, 
> HBASE-19114.master.006.patch
>
>
> Changes so far:
> - Moved DrainingServerTracker and RegionServerTracker to 
> hbase-server:o.a.h.h.master.
> - Moved SplitOrMergeTracker to oahh.master (because it depends on a PB)
> - Moving hbase-client:oahh.zookeeper.*  to hbase-zookeeper module.  After 
> [~Apache9]'s cleanup (HBASE-19200), hbase-client doesn't need them anymore 
> (except 3 classes).
> - Renamed some classes to use a consistent naming for classes - ZK instead of 
> mix of ZK, Zk , ZooKeeper. Couldn't rename following public classes: 
> MiniZooKeeperCluster, ZooKeeperConnectionException. Left RecoverableZooKeeper 
> for lack of better name. (suggestions?)
> - Sadly, can't move tests out because they depend on HBaseTestingUtility 
> (which defeats part of the purpose - trimming down hbase-server tests. We 
> need to promote more use of mocks in our tests)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19114) Split out o.a.h.h.zookeeper from hbase-server and hbase-client

[Appy (JIRA)]

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

Appy updated HBASE-19114:
-
Attachment: HBASE-19114.master.006.patch

> Split out o.a.h.h.zookeeper from hbase-server and hbase-client
> --
>
> Key: HBASE-19114
> URL: https://issues.apache.org/jira/browse/HBASE-19114
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19114.master.001.patch, 
> HBASE-19114.master.002.patch, HBASE-19114.master.003.patch, 
> HBASE-19114.master.004.patch, HBASE-19114.master.005.patch, 
> HBASE-19114.master.006.patch
>
>
> Changes so far:
> - Moved DrainingServerTracker and RegionServerTracker to 
> hbase-server:o.a.h.h.master.
> - Moved SplitOrMergeTracker to oahh.master (because it depends on a PB)
> - Moving hbase-client:oahh.zookeeper.*  to hbase-zookeeper module.  After 
> [~Apache9]'s cleanup (HBASE-19200), hbase-client doesn't need them anymore 
> (except 3 classes).
> - Renamed some classes to use a consistent naming for classes - ZK instead of 
> mix of ZK, Zk , ZooKeeper. Couldn't rename following public classes: 
> MiniZooKeeperCluster, ZooKeeperConnectionException. Left RecoverableZooKeeper 
> for lack of better name. (suggestions?)
> - Sadly, can't move tests out because they depend on HBaseTestingUtility 
> (which defeats part of the purpose - trimming down hbase-server tests. We 
> need to promote more use of mocks in our tests)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19255) PerformanceEvaluation class not found when run PE test

[Guanghao Zhang (JIRA)]

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

Guanghao Zhang commented on HBASE-19255:


Maybe another way to resolve this is move PerformanceEvaluation to hbase-server 
module?

> PerformanceEvaluation class not found when run PE test
> --
>
> Key: HBASE-19255
> URL: https://issues.apache.org/jira/browse/HBASE-19255
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 3.0.0, 2.0.0-beta-1
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 3.0.0, 2.0.0-beta-1
>
> Attachments: HBASE-19255.master.001.patch
>
>
> {code}
> mvn clean package install -DskipTests
> ./hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=1 --nomapred 
> randomWrite 1
> {code}
> PerformanceEvaluation is in hbase-mapreduce module's test jar. After 
> HBASE-18640, we move mapreduce out of hbase-server into separate 
> hbase-mapreduce module. But didn't add the hbase-mapreduce test jar to 
> hbase-assembly pom.xml. So it didn't add to the default classpath. Then the 
> PerformanceEvaluation can't found.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18963) Remove MultiRowMutationProcessor and implement mutateRows... methods using batchMutate()

[Umesh Agashe (JIRA)]

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

Umesh Agashe updated HBASE-18963:
-
Attachment: hbase-18963.master.005.patch

retry

> Remove MultiRowMutationProcessor and implement mutateRows... methods using 
> batchMutate()
> 
>
> Key: HBASE-18963
> URL: https://issues.apache.org/jira/browse/HBASE-18963
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0-alpha-3
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0-beta-1
>
> Attachments: hbase-18963.master.001.patch, 
> hbase-18963.master.002.patch, hbase-18963.master.003.patch, 
> hbase-18963.master.004.patch, hbase-18963.master.005.patch, 
> hbase-18963.master.005.patch
>
>
> Remove MultiRowMutationProcessor and implement mutateRows... methods using 
> batchMutate()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19009) implement modifyTable and enable/disableTableReplication for AsyncAdmin

[Guanghao Zhang (JIRA)]

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

Guanghao Zhang commented on HBASE-19009:


[~appy] Any more concerns? If no, I will fix the checkstyle problem when 
commit. Thanks for your great review.

> implement modifyTable and enable/disableTableReplication for AsyncAdmin
> ---
>
> Key: HBASE-19009
> URL: https://issues.apache.org/jira/browse/HBASE-19009
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 3.0.0, 2.0.0-beta-1
>
> Attachments: HBASE-19009.master.001.patch, 
> HBASE-19009.master.002.patch, HBASE-19009.master.003.patch, 
> HBASE-19009.master.004.patch, HBASE-19009.master.005.patch, 
> HBASE-19009.master.006.patch, HBASE-19009.master.007.patch, 
> HBASE-19009.master.008.patch, HBASE-19009.master.009.patch, 
> HBASE-19009.master.010.patch, HBASE-19009.master.011.patch
>
>
> Add 3 methods to AsyncAdmin.
> modifyTable()
> enableTableReplication()
> disableTableReplication()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19114) Split out o.a.h.h.zookeeper from hbase-server and hbase-client

[Appy (JIRA)]

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

Appy updated HBASE-19114:
-
Description: 
Changes so far:
- Moved DrainingServerTracker and RegionServerTracker to 
hbase-server:o.a.h.h.master.
- Moved SplitOrMergeTracker to oahh.master (because it depends on a PB)
- Moving hbase-client:oahh.zookeeper.*  to hbase-zookeeper module.  After 
[~Apache9]'s cleanup (HBASE-19200), hbase-client doesn't need them anymore 
(except 3 classes).
- Renamed some classes to use a consistent naming for classes - ZK instead of 
mix of ZK, Zk , ZooKeeper. Couldn't rename following public classes: 
MiniZooKeeperCluster, ZooKeeperConnectionException. Left RecoverableZooKeeper 
for lack of better name. (suggestions?)
- Sadly, can't move tests out because they depend on HBaseTestingUtility (which 
defeats part of the purpose - trimming down hbase-server tests. We need to 
promote more use of mocks in our tests)

  was:
Changes so far:

- Moved DrainingServerTracker and RegionServerTracker to 
hbase-server:o.a.h.h.master.
- Moved SplitOrMergeTracker to oahh.master (because it depends on a PB)
- Moving hbase-client:oahh.zookeeper.*  to hbase-zookeeper module.  After 
[~Apache9]'s cleanup (HBASE-19200), hbase-client doesn't need them anymore 
(except 3 classes).
- Renamed some classes to use a consistent naming for classes - ZK instead of 
mix of ZK, Zk , ZooKeeper. Couldn't rename following public classes: 
MiniZooKeeperCluster, ZooKeeperConnectionException.


> Split out o.a.h.h.zookeeper from hbase-server and hbase-client
> --
>
> Key: HBASE-19114
> URL: https://issues.apache.org/jira/browse/HBASE-19114
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19114.master.001.patch, 
> HBASE-19114.master.002.patch, HBASE-19114.master.003.patch, 
> HBASE-19114.master.004.patch, HBASE-19114.master.005.patch
>
>
> Changes so far:
> - Moved DrainingServerTracker and RegionServerTracker to 
> hbase-server:o.a.h.h.master.
> - Moved SplitOrMergeTracker to oahh.master (because it depends on a PB)
> - Moving hbase-client:oahh.zookeeper.*  to hbase-zookeeper module.  After 
> [~Apache9]'s cleanup (HBASE-19200), hbase-client doesn't need them anymore 
> (except 3 classes).
> - Renamed some classes to use a consistent naming for classes - ZK instead of 
> mix of ZK, Zk , ZooKeeper. Couldn't rename following public classes: 
> MiniZooKeeperCluster, ZooKeeperConnectionException. Left RecoverableZooKeeper 
> for lack of better name. (suggestions?)
> - Sadly, can't move tests out because they depend on HBaseTestingUtility 
> (which defeats part of the purpose - trimming down hbase-server tests. We 
> need to promote more use of mocks in our tests)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18963) Remove MultiRowMutationProcessor and implement mutateRows... methods using batchMutate()

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-18963:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
12s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  0m  
0s{color} | {color:blue} Findbugs executables are not available. {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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
 6s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
46s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
29s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  5m 
 4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
14s{color} | {color:green} hbase-server: The patch generated 0 new + 346 
unchanged - 8 fixed = 346 total (was 354) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
 3s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
56m 42s{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 2.7.4 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
28s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}111m 25s{color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
18s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}188m  4s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-18963 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12897619/hbase-18963.master.005.patch
 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 5e68309a1d7d 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11 
12:48:20 UTC 2017 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 / f9b19c6e33 |
| maven | version: Apache Maven 3.5.2 
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9804/artifact/patchprocess/patch-unit-hbase-server.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9804/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output | 

[jira] [Updated] (HBASE-19114) Split out o.a.h.h.zookeeper from hbase-server and hbase-client

[Appy (JIRA)]

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

Appy updated HBASE-19114:
-
Description: 
Changes so far:

- Moved DrainingServerTracker and RegionServerTracker to 
hbase-server:o.a.h.h.master.
- Moved SplitOrMergeTracker to oahh.master (because it depends on a PB)
- Moving hbase-client:oahh.zookeeper.*  to hbase-zookeeper module.  After 
[~Apache9]'s cleanup (HBASE-19200), hbase-client doesn't need them anymore 
(except 3 classes).
- Renamed some classes to use a consistent naming for classes - ZK instead of 
mix of ZK, Zk , ZooKeeper. Couldn't rename following public classes: 
MiniZooKeeperCluster, ZooKeeperConnectionException.

  was:
Changes so far:

- Moved DrainingServerTracker and RegionServerTracker to 
hbase-server:o.a.h.h.master.
- Move Abortable to hbase-common. Since it's IA.Private and independent of 
anything, moving it to hbase-common which is at bottom of the dependency tree 
is better.
- Moved RecoveringRegionWatcher to hbase-server:o.a.h.h.regionserver
- Moved SplitOrMergeTracker to oahh.master (because it depends on a PB)
- Moving hbase-client:oahh.zookeeper.*  to hbase-zookeeper module. We want to 
keep hbase-zookeeper very independent and hence at lowest levels in our 
dependency tree.
- ZKUtil is a huge tangle since it's linked to almost everything in 
\[hbase-client/]oahh.zookeeper. And pulling it down requires some basic proto 
functions (mergeFrom, PBmagic, etc). So what i did was:
   ** Pulled down common and basic protobuf functions (which only depend on 
com.google.protobuf.\*) to hbase-common so other code depending on them can be 
pulled down if possible/wanted in future. This will help future dependency 
untangling too. These are ProtobufMagic and ProtobufHelpers.
  ** Didn't move any hbase-specific PB stuff to hbase-common. We can't pull 
things into hbase-common which add dependency between it and 
hbase-protobuf/hbase-shaded-protobuf since we very recently untangled them.
- DEFAULT_REPLICA_ID is used in many places in ZK. Declared a new constant in 
HConstants (since it's in hbase-common) and using it in hbase-zookeeper. 
RegionInfo.DEFAULT_REPLICA_ID also takes its value from it to avoid case where 
two values can become different.
- Renamed some classes to use a consistent naming for classes - ZK instead of 
mix of ZK, Zk , ZooKeeper. Couldn't rename following public classes: 
MiniZooKeeperCluster, ZooKeeperConnectionException.


> Split out o.a.h.h.zookeeper from hbase-server and hbase-client
> --
>
> Key: HBASE-19114
> URL: https://issues.apache.org/jira/browse/HBASE-19114
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19114.master.001.patch, 
> HBASE-19114.master.002.patch, HBASE-19114.master.003.patch, 
> HBASE-19114.master.004.patch, HBASE-19114.master.005.patch
>
>
> Changes so far:
> - Moved DrainingServerTracker and RegionServerTracker to 
> hbase-server:o.a.h.h.master.
> - Moved SplitOrMergeTracker to oahh.master (because it depends on a PB)
> - Moving hbase-client:oahh.zookeeper.*  to hbase-zookeeper module.  After 
> [~Apache9]'s cleanup (HBASE-19200), hbase-client doesn't need them anymore 
> (except 3 classes).
> - Renamed some classes to use a consistent naming for classes - ZK instead of 
> mix of ZK, Zk , ZooKeeper. Couldn't rename following public classes: 
> MiniZooKeeperCluster, ZooKeeperConnectionException.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19210) TestNamespacesInstanceResource fails

[Hudson (JIRA)]

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

Hudson commented on HBASE-19210:


FAILURE: Integrated in Jenkins build HBase-2.0 #852 (See 
[https://builds.apache.org/job/HBase-2.0/852/])
HBASE-19210 TestNamespacesInstanceResource fails (tedyu: rev 
76b9d4617c657b8e5a5244f06ff6c4165c69896e)
* (edit) 
hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestNamespacesInstanceResource.java


> TestNamespacesInstanceResource fails
> 
>
> Key: HBASE-19210
> URL: https://issues.apache.org/jira/browse/HBASE-19210
> Project: HBase
>  Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19210-addendum-3.txt, 19210-addendum-4.txt, 
> 19210-addendum-5.txt, 19210.addendum, 19210.v1.txt, 19210.v1.txt, 
> 19210.v2.txt, 19210.v3.txt, HBASE-19210.WIP.patch
>
>
> This is the top flaky test.
> The following can be reproduced:
> {code}
> java.net.SocketException: Connection reset
>   at 
> org.apache.hadoop.hbase.rest.TestNamespacesInstanceResource.testInvalidNamespacePostsAndPuts(TestNamespacesInstanceResource.java:271)
> {code}
> With commit e320df5a0c267258c03909da8d0eee4c0e287532, the test passes.
> With commit 5facaded902a13556952b1f9d26b768cb86e6599, the test fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-16574) Add backup / restore feature to refguide

[Vladimir Rodionov (JIRA)]

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

Vladimir Rodionov commented on HBASE-16574:
---

[~elserj], can you check command usage examples? Some of them have missing -t 
in front of table lists? This is for both: backup and restore commands. This is 
a new format, one always have to list tables through -t option (or -s for table 
sets).

> Add backup / restore feature to refguide
> 
>
> Key: HBASE-16574
> URL: https://issues.apache.org/jira/browse/HBASE-16574
> Project: HBase
>  Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Frank Welsch
>  Labels: backup
> Fix For: 2.0.0-beta-1
>
> Attachments: B command-line tools and configuration (updated).pdf, 
> Backup-and-Restore-Apache_19Sep2016.pdf, HBASE-16574.001.patch, 
> HBASE-16574.002.patch, HBASE-16574.003.branch-2.patch, 
> HBASE-16574.004.branch-2.patch, apache_hbase_reference_guide_004.pdf, 
> hbase-book-16574.003.pdf, hbase_reference_guide.v1.pdf
>
>
> This issue is to add backup / restore feature description to hbase refguide.
> The description should cover:
> scenarios where backup / restore is used
> backup / restore commands and sample usage
> considerations in setup



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)