[jira] [Commented] (HBASE-20449) the minimun number of region should be configurable in normalizable
[
https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441912#comment-16441912
]
Hadoop QA commented on HBASE-20449:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
21s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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: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
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
47s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 3m
41s{color} | {color:blue} branch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
2s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
45s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 1m
54s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 1m
32s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 1m 32s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
10s{color} | {color:red} hbase-server: The patch generated 1 new + 0 unchanged
- 0 fixed = 1 total (was 0) {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
2s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 3m
16s{color} | {color:blue} patch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
| {color:red}-1{color} | {color:red} shadedjars {color} | {color:red} 3m
30s{color} | {color:red} patch has 17 errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
50s{color} | {color:red} The patch causes 18 errors with Hadoop v2.6.5. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m
38s{color} | {color:red} The patch causes 18 errors with Hadoop v2.7.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m
37s{color} | {color:red} The patch causes 18 errors with Hadoop v3.0.0. {color}
|
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
28s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
46s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
24s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 47s{color}
| {color:red} hbase-server in the patch
[jira] [Commented] (HBASE-20449) the minimun number of region should be configurable in normalizable
[ https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441900#comment-16441900 ] Ted Yu commented on HBASE-20449: There is no need to declare Configuration as a field. You can instantiate it in the ctor. > the minimun number of region should be configurable in normalizable > --- > > Key: HBASE-20449 > URL: https://issues.apache.org/jira/browse/HBASE-20449 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0 >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20449_001.patch, HBASE-20449_002.patch, > HBASE-20449_003.patch > > > the minimun number of region should be configurable in normalizable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19761) Fix Checkstyle errors in hbase-zookeeper
[ https://issues.apache.org/jira/browse/HBASE-19761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maoling updated HBASE-19761: Attachment: HBASE-19761-master-v3.patch > Fix Checkstyle errors in hbase-zookeeper > > > Key: HBASE-19761 > URL: https://issues.apache.org/jira/browse/HBASE-19761 > Project: HBase > Issue Type: Sub-task >Reporter: Jan Hentschel >Assignee: maoling >Priority: Minor > Attachments: HBASE-19761-master-v0.patch, > HBASE-19761-master-v1.patch, HBASE-19761-master-v2.patch, > HBASE-19761-master-v3.patch > > > Fix the remaining Checkstyle errors in the *hbase-zookeeper* module and > enable Checkstyle to fail on violations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20449) the minimun number of region should be configurable in normalizable
[ https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441895#comment-16441895 ] Yu Wang commented on HBASE-20449: - [~yuzhih...@gmail.com] thank you for your answer ! I have already edited it. > the minimun number of region should be configurable in normalizable > --- > > Key: HBASE-20449 > URL: https://issues.apache.org/jira/browse/HBASE-20449 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0 >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20449_001.patch, HBASE-20449_002.patch, > HBASE-20449_003.patch > > > the minimun number of region should be configurable in normalizable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19761) Fix Checkstyle errors in hbase-zookeeper
[ https://issues.apache.org/jira/browse/HBASE-19761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maoling updated HBASE-19761: Attachment: (was: HBASE-19761.master.v3.patch) > Fix Checkstyle errors in hbase-zookeeper > > > Key: HBASE-19761 > URL: https://issues.apache.org/jira/browse/HBASE-19761 > Project: HBase > Issue Type: Sub-task >Reporter: Jan Hentschel >Assignee: maoling >Priority: Minor > Attachments: HBASE-19761-master-v0.patch, > HBASE-19761-master-v1.patch, HBASE-19761-master-v2.patch > > > Fix the remaining Checkstyle errors in the *hbase-zookeeper* module and > enable Checkstyle to fail on violations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20449) the minimun number of region should be configurable in normalizable
[ https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Wang updated HBASE-20449: Attachment: HBASE-20449_003.patch > the minimun number of region should be configurable in normalizable > --- > > Key: HBASE-20449 > URL: https://issues.apache.org/jira/browse/HBASE-20449 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0 >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20449_001.patch, HBASE-20449_002.patch, > HBASE-20449_003.patch > > > the minimun number of region should be configurable in normalizable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19761) Fix Checkstyle errors in hbase-zookeeper
[ https://issues.apache.org/jira/browse/HBASE-19761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maoling updated HBASE-19761: Attachment: HBASE-19761.master.v3.patch > Fix Checkstyle errors in hbase-zookeeper > > > Key: HBASE-19761 > URL: https://issues.apache.org/jira/browse/HBASE-19761 > Project: HBase > Issue Type: Sub-task >Reporter: Jan Hentschel >Assignee: maoling >Priority: Minor > Attachments: HBASE-19761-master-v0.patch, > HBASE-19761-master-v1.patch, HBASE-19761-master-v2.patch, > HBASE-19761.master.v3.patch > > > Fix the remaining Checkstyle errors in the *hbase-zookeeper* module and > enable Checkstyle to fail on violations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20293) get_splits returns duplicate split points when region replication is on
[
https://issues.apache.org/jira/browse/HBASE-20293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441886#comment-16441886
]
Hudson commented on HBASE-20293:
Results for branch branch-2.0
[build #190 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/190/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/190//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/190//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/190//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> get_splits returns duplicate split points when region replication is on
> ---
>
> Key: HBASE-20293
> URL: https://issues.apache.org/jira/browse/HBASE-20293
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Minor
> Attachments: HBASE-20293.master.001.patch,
> HBASE-20293.master.002.patch, HBASE-20293.master.003.patch,
> HBASE-20293.master.004.patch
>
>
> When region replication is on, get_splits returns duplicate split points like
> the following:
> {code}
> hbase(main):001:0> create "test", "cf", {REGION_REPLICATION => 3}, SPLITS =>
> ["10"]
> Created table test
> Took 1.0975 seconds
> hbase(main):002:0> get_splits "test"
> Total number of splits = 4
> 10
> 10
> 10
> Took 0.0941 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20439) Clean up incorrect use of commons-logging in hbase-server
[
https://issues.apache.org/jira/browse/HBASE-20439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441883#comment-16441883
]
Hadoop QA commented on HBASE-20439:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 5 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {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} 1m
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
11s{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} findbugs {color} | {color:green} 2m
32s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
54s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 8m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
59s{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} 7m
34s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
25m 41s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
55s{color} | {color:green} the patch passed {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:green}+1{color} | {color:green} unit {color} | {color:green}110m
39s{color} | {color:green} hbase-server in the patch passed. {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}178m 7s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20439 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12919514/HBASE-20439.1.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux b35f33b7e7ee 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / fd2cec75f3 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12510/testReport/ |
| Max. process+thread count | 4278 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12510/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Clean up incorrect use of
[jira] [Commented] (HBASE-20378) Provide a hbck option to cleanup replication barrier for a table
[
https://issues.apache.org/jira/browse/HBASE-20378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441882#comment-16441882
]
Hadoop QA commented on HBASE-20378:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
5s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
32s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
16s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
25s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
32s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
0s{color} | {color:red} hbase-server: The patch generated 3 new + 101 unchanged
- 0 fixed = 104 total (was 101) {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git
apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply
{color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
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}
12m 54s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
23s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}107m 52s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}148m 6s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestWALLockup |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20378 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12919350/HBASE-20378.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 2b2391187633 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 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 / fd2cec75f3 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/12512/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| whitespace |
[jira] [Commented] (HBASE-20449) the minimun number of region should be configurable in normalizable
[ https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441874#comment-16441874 ] Yu Wang commented on HBASE-20449: - [~yuzhih...@gmail.com] thank you for your answer ! I have already edited it. > the minimun number of region should be configurable in normalizable > --- > > Key: HBASE-20449 > URL: https://issues.apache.org/jira/browse/HBASE-20449 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0 >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20449_001.patch, HBASE-20449_002.patch > > > the minimun number of region should be configurable in normalizable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20449) the minimun number of region should be configurable in normalizable
[ https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Wang updated HBASE-20449: Attachment: (was: HBASE-20449_003.patch) > the minimun number of region should be configurable in normalizable > --- > > Key: HBASE-20449 > URL: https://issues.apache.org/jira/browse/HBASE-20449 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0 >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20449_001.patch, HBASE-20449_002.patch > > > the minimun number of region should be configurable in normalizable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (HBASE-20449) the minimun number of region should be configurable in normalizable
[ https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Wang updated HBASE-20449: Comment: was deleted (was: [~yuzhih...@gmail.com] thank you for your answer ! I have already edited it.) > the minimun number of region should be configurable in normalizable > --- > > Key: HBASE-20449 > URL: https://issues.apache.org/jira/browse/HBASE-20449 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0 >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20449_001.patch, HBASE-20449_002.patch > > > the minimun number of region should be configurable in normalizable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20449) the minimun number of region should be configurable in normalizable
[ https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Wang updated HBASE-20449: Attachment: HBASE-20449_003.patch > the minimun number of region should be configurable in normalizable > --- > > Key: HBASE-20449 > URL: https://issues.apache.org/jira/browse/HBASE-20449 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0 >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20449_001.patch, HBASE-20449_002.patch, > HBASE-20449_003.patch > > > the minimun number of region should be configurable in normalizable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20293) get_splits returns duplicate split points when region replication is on
[
https://issues.apache.org/jira/browse/HBASE-20293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441867#comment-16441867
]
Hudson commented on HBASE-20293:
Results for branch branch-2
[build #627 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/627/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/627//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/627//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/627//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> get_splits returns duplicate split points when region replication is on
> ---
>
> Key: HBASE-20293
> URL: https://issues.apache.org/jira/browse/HBASE-20293
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Minor
> Attachments: HBASE-20293.master.001.patch,
> HBASE-20293.master.002.patch, HBASE-20293.master.003.patch,
> HBASE-20293.master.004.patch
>
>
> When region replication is on, get_splits returns duplicate split points like
> the following:
> {code}
> hbase(main):001:0> create "test", "cf", {REGION_REPLICATION => 3}, SPLITS =>
> ["10"]
> Created table test
> Took 1.0975 seconds
> hbase(main):002:0> get_splits "test"
> Total number of splits = 4
> 10
> 10
> 10
> Took 0.0941 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20449) the minimun number of region should be configurable in normalizable
[
https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441857#comment-16441857
]
Ted Yu commented on HBASE-20449:
{code}
[ERROR]
/testptch/hbase/hbase-server/src/test/java/org/apache/hadoop/hbase/master/normalizer/TestSimpleRegionNormalizer.java:[81,18]
constructor SimpleRegionNormalizer in class
org.apache.hadoop.hbase.master.normalizer.SimpleRegionNormalizer cannot be
applied to given types;
required: org.apache.hadoop.hbase.HBaseConfiguration
found: no arguments
reason: actual and formal argument lists differ in length
{code}
You can either reintroduce the no-arg ctor or, modify the test to pass
HBaseConfiguration instance.
> the minimun number of region should be configurable in normalizable
> ---
>
> Key: HBASE-20449
> URL: https://issues.apache.org/jira/browse/HBASE-20449
> Project: HBase
> Issue Type: Improvement
> Components: hbase
>Affects Versions: 3.0.0
>Reporter: Yu Wang
>Assignee: Yu Wang
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: HBASE-20449_001.patch, HBASE-20449_002.patch
>
>
> the minimun number of region should be configurable in normalizable
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20449) the minimun number of region should be configurable in normalizable
[
https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441851#comment-16441851
]
Hadoop QA commented on HBASE-20449:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
14s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
36s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 3m
16s{color} | {color:blue} branch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
51s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
58s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
17s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 2m
23s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 1m
52s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 1m 52s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
18s{color} | {color:red} hbase-server: The patch generated 1 new + 0 unchanged
- 0 fixed = 1 total (was 0) {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
2s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 3m
51s{color} | {color:blue} patch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
| {color:red}-1{color} | {color:red} shadedjars {color} | {color:red} 3m
54s{color} | {color:red} patch has 17 errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m
18s{color} | {color:red} The patch causes 18 errors with Hadoop v2.6.5. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 4m
28s{color} | {color:red} The patch causes 18 errors with Hadoop v2.7.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m
56s{color} | {color:red} The patch causes 18 errors with Hadoop v3.0.0. {color}
|
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
34s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
44s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 56s{color}
| {color:red} hbase-server in the patch
[jira] [Commented] (HBASE-19850) The number of Offline Regions is wrong after restoring a snapshot
[
https://issues.apache.org/jira/browse/HBASE-19850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441850#comment-16441850
]
Toshihiro Suzuki commented on HBASE-19850:
--
Thank you for reviewing and committing the patch, Ted.
> The number of Offline Regions is wrong after restoring a snapshot
> -
>
> Key: HBASE-19850
> URL: https://issues.apache.org/jira/browse/HBASE-19850
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 1.5.0
>
> Attachments: HBASE-19850-branch-1.patch,
> HBASE-19850.branch-1.001.patch, HBASE-19850.branch-1.001.patch, The number of
> Offline Regions.png
>
>
> Steps to reproduce are as follows:
> 1. Create a table
> {code:java}
> create "test", "cf"
> {code}
> 2. Take a snapshot for the table
> {code:java}
> snapshot "test", "snap"
> {code}
> 3. Load data to the table
> {code:java}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 4. Split regions of the table
> {code:java}
> split "test"
> {code}
> 5. Restore the table from the snapshot
> {code:java}
> disable "test"
> restore_snapshot "snap"
> enable "test"
> {code}
>
> The number of Offline Regions is as follows:
> !The number of Offline Regions.png!
> The number of Offline Regions should be zero.
> It seems like when regions are removed by restoring a snapshot, the number of
> Offline Regions becomes wrong. And as far as I reviewed the code, it seems
> like the Offline Regions will not be cleaned up. After restarting Master, the
> offline regions disappear.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-19850) The number of Offline Regions is wrong after restoring a snapshot
[
https://issues.apache.org/jira/browse/HBASE-19850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-19850:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Thanks for the patch, Toshihiro
> The number of Offline Regions is wrong after restoring a snapshot
> -
>
> Key: HBASE-19850
> URL: https://issues.apache.org/jira/browse/HBASE-19850
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 1.5.0
>
> Attachments: HBASE-19850-branch-1.patch,
> HBASE-19850.branch-1.001.patch, HBASE-19850.branch-1.001.patch, The number of
> Offline Regions.png
>
>
> Steps to reproduce are as follows:
> 1. Create a table
> {code:java}
> create "test", "cf"
> {code}
> 2. Take a snapshot for the table
> {code:java}
> snapshot "test", "snap"
> {code}
> 3. Load data to the table
> {code:java}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 4. Split regions of the table
> {code:java}
> split "test"
> {code}
> 5. Restore the table from the snapshot
> {code:java}
> disable "test"
> restore_snapshot "snap"
> enable "test"
> {code}
>
> The number of Offline Regions is as follows:
> !The number of Offline Regions.png!
> The number of Offline Regions should be zero.
> It seems like when regions are removed by restoring a snapshot, the number of
> Offline Regions becomes wrong. And as far as I reviewed the code, it seems
> like the Offline Regions will not be cleaned up. After restarting Master, the
> offline regions disappear.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-18059) The scanner order for memstore scanners are wrong
[
https://issues.apache.org/jira/browse/HBASE-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441839#comment-16441839
]
Jingyun Tian commented on HBASE-18059:
--
IMO the scanner order for memstore is actually useless. I removed all code of
scanner order in memstore related classes. This patch passed test at my local
PC.
> The scanner order for memstore scanners are wrong
> -
>
> Key: HBASE-18059
> URL: https://issues.apache.org/jira/browse/HBASE-18059
> Project: HBase
> Issue Type: Bug
> Components: regionserver, scan, Scanners
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-18059.master.001.patch
>
>
> This is comments for KeyValueScanner.getScannerOrder
> {code:title=KeyValueScanner.java}
> /**
>* Get the order of this KeyValueScanner. This is only relevant for
> StoreFileScanners and
>* MemStoreScanners (other scanners simply return 0). This is required for
> comparing multiple
>* files to find out which one has the latest data. StoreFileScanners are
> ordered from 0
>* (oldest) to newest in increasing order. MemStoreScanner gets LONG.max
> since it always
>* contains freshest data.
>*/
> long getScannerOrder();
> {code}
> As now we may have multiple memstore scanners, I think the right way to
> select scanner order for memstore scanner is to ordered from Long.MAX_VALUE
> in decreasing order.
> But in CompactingMemStore and DefaultMemStore, the scanner order for memstore
> scanner is also start from 0, which will be messed up with StoreFileScanners.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-18059) The scanner order for memstore scanners are wrong
[
https://issues.apache.org/jira/browse/HBASE-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jingyun Tian updated HBASE-18059:
-
Attachment: (was: HBASE-18059.master.002.patch)
> The scanner order for memstore scanners are wrong
> -
>
> Key: HBASE-18059
> URL: https://issues.apache.org/jira/browse/HBASE-18059
> Project: HBase
> Issue Type: Bug
> Components: regionserver, scan, Scanners
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-18059.master.001.patch
>
>
> This is comments for KeyValueScanner.getScannerOrder
> {code:title=KeyValueScanner.java}
> /**
>* Get the order of this KeyValueScanner. This is only relevant for
> StoreFileScanners and
>* MemStoreScanners (other scanners simply return 0). This is required for
> comparing multiple
>* files to find out which one has the latest data. StoreFileScanners are
> ordered from 0
>* (oldest) to newest in increasing order. MemStoreScanner gets LONG.max
> since it always
>* contains freshest data.
>*/
> long getScannerOrder();
> {code}
> As now we may have multiple memstore scanners, I think the right way to
> select scanner order for memstore scanner is to ordered from Long.MAX_VALUE
> in decreasing order.
> But in CompactingMemStore and DefaultMemStore, the scanner order for memstore
> scanner is also start from 0, which will be messed up with StoreFileScanners.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-18059) The scanner order for memstore scanners are wrong
[
https://issues.apache.org/jira/browse/HBASE-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jingyun Tian updated HBASE-18059:
-
Status: Patch Available (was: Open)
> The scanner order for memstore scanners are wrong
> -
>
> Key: HBASE-18059
> URL: https://issues.apache.org/jira/browse/HBASE-18059
> Project: HBase
> Issue Type: Bug
> Components: regionserver, scan, Scanners
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-18059.master.001.patch
>
>
> This is comments for KeyValueScanner.getScannerOrder
> {code:title=KeyValueScanner.java}
> /**
>* Get the order of this KeyValueScanner. This is only relevant for
> StoreFileScanners and
>* MemStoreScanners (other scanners simply return 0). This is required for
> comparing multiple
>* files to find out which one has the latest data. StoreFileScanners are
> ordered from 0
>* (oldest) to newest in increasing order. MemStoreScanner gets LONG.max
> since it always
>* contains freshest data.
>*/
> long getScannerOrder();
> {code}
> As now we may have multiple memstore scanners, I think the right way to
> select scanner order for memstore scanner is to ordered from Long.MAX_VALUE
> in decreasing order.
> But in CompactingMemStore and DefaultMemStore, the scanner order for memstore
> scanner is also start from 0, which will be messed up with StoreFileScanners.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-18059) The scanner order for memstore scanners are wrong
[
https://issues.apache.org/jira/browse/HBASE-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jingyun Tian updated HBASE-18059:
-
Attachment: HBASE-18059.master.002.patch
> The scanner order for memstore scanners are wrong
> -
>
> Key: HBASE-18059
> URL: https://issues.apache.org/jira/browse/HBASE-18059
> Project: HBase
> Issue Type: Bug
> Components: regionserver, scan, Scanners
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-18059.master.001.patch,
> HBASE-18059.master.002.patch
>
>
> This is comments for KeyValueScanner.getScannerOrder
> {code:title=KeyValueScanner.java}
> /**
>* Get the order of this KeyValueScanner. This is only relevant for
> StoreFileScanners and
>* MemStoreScanners (other scanners simply return 0). This is required for
> comparing multiple
>* files to find out which one has the latest data. StoreFileScanners are
> ordered from 0
>* (oldest) to newest in increasing order. MemStoreScanner gets LONG.max
> since it always
>* contains freshest data.
>*/
> long getScannerOrder();
> {code}
> As now we may have multiple memstore scanners, I think the right way to
> select scanner order for memstore scanner is to ordered from Long.MAX_VALUE
> in decreasing order.
> But in CompactingMemStore and DefaultMemStore, the scanner order for memstore
> scanner is also start from 0, which will be messed up with StoreFileScanners.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19850) The number of Offline Regions is wrong after restoring a snapshot
[
https://issues.apache.org/jira/browse/HBASE-19850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441838#comment-16441838
]
Toshihiro Suzuki commented on HBASE-19850:
--
[~yuzhih...@gmail.com] I was able to apply the patch to branch-1 using 'git am'
locally. Thanks.
> The number of Offline Regions is wrong after restoring a snapshot
> -
>
> Key: HBASE-19850
> URL: https://issues.apache.org/jira/browse/HBASE-19850
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 1.5.0
>
> Attachments: HBASE-19850-branch-1.patch,
> HBASE-19850.branch-1.001.patch, HBASE-19850.branch-1.001.patch, The number of
> Offline Regions.png
>
>
> Steps to reproduce are as follows:
> 1. Create a table
> {code:java}
> create "test", "cf"
> {code}
> 2. Take a snapshot for the table
> {code:java}
> snapshot "test", "snap"
> {code}
> 3. Load data to the table
> {code:java}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 4. Split regions of the table
> {code:java}
> split "test"
> {code}
> 5. Restore the table from the snapshot
> {code:java}
> disable "test"
> restore_snapshot "snap"
> enable "test"
> {code}
>
> The number of Offline Regions is as follows:
> !The number of Offline Regions.png!
> The number of Offline Regions should be zero.
> It seems like when regions are removed by restoring a snapshot, the number of
> Offline Regions becomes wrong. And as far as I reviewed the code, it seems
> like the Offline Regions will not be cleaned up. After restarting Master, the
> offline regions disappear.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-18059) The scanner order for memstore scanners are wrong
[
https://issues.apache.org/jira/browse/HBASE-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jingyun Tian updated HBASE-18059:
-
Attachment: HBASE-18059.master.001.patch
> The scanner order for memstore scanners are wrong
> -
>
> Key: HBASE-18059
> URL: https://issues.apache.org/jira/browse/HBASE-18059
> Project: HBase
> Issue Type: Bug
> Components: regionserver, scan, Scanners
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-18059.master.001.patch
>
>
> This is comments for KeyValueScanner.getScannerOrder
> {code:title=KeyValueScanner.java}
> /**
>* Get the order of this KeyValueScanner. This is only relevant for
> StoreFileScanners and
>* MemStoreScanners (other scanners simply return 0). This is required for
> comparing multiple
>* files to find out which one has the latest data. StoreFileScanners are
> ordered from 0
>* (oldest) to newest in increasing order. MemStoreScanner gets LONG.max
> since it always
>* contains freshest data.
>*/
> long getScannerOrder();
> {code}
> As now we may have multiple memstore scanners, I think the right way to
> select scanner order for memstore scanner is to ordered from Long.MAX_VALUE
> in decreasing order.
> But in CompactingMemStore and DefaultMemStore, the scanner order for memstore
> scanner is also start from 0, which will be messed up with StoreFileScanners.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20449) the minimun number of region should be configurable in normalizable
[ https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441814#comment-16441814 ] Ted Yu commented on HBASE-20449: Can you use dev-support/submit-patch.py to generate patch ? This way, you would appear as the author of the commit. Hopefully patch v2 doesn't have compilation error. Since MIN_REGION_COUNT is no longer a constant, you can name it minRegionCount. > the minimun number of region should be configurable in normalizable > --- > > Key: HBASE-20449 > URL: https://issues.apache.org/jira/browse/HBASE-20449 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0 >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20449_001.patch, HBASE-20449_002.patch > > > the minimun number of region should be configurable in normalizable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20449) the minimun number of region should be configurable in normalizable
[
https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441811#comment-16441811
]
Hadoop QA commented on HBASE-20449:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 2m
5s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
14s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
59s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
34s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 3m
34s{color} | {color:blue} branch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
45s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
44s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 1m
52s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 1m
31s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 1m 31s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
9s{color} | {color:red} hbase-server: The patch generated 1 new + 0 unchanged -
0 fixed = 1 total (was 0) {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
2s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 3m
10s{color} | {color:blue} patch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
| {color:red}-1{color} | {color:red} shadedjars {color} | {color:red} 3m
25s{color} | {color:red} patch has 17 errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
54s{color} | {color:red} The patch causes 18 errors with Hadoop v2.6.5. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m
41s{color} | {color:red} The patch causes 18 errors with Hadoop v2.7.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m
44s{color} | {color:red} The patch causes 18 errors with Hadoop v3.0.0. {color}
|
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
25s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
43s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
15s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 41s{color}
| {color:red} hbase-server in the patch
[jira] [Commented] (HBASE-20449) the minimun number of region should be configurable in normalizable
[ https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441807#comment-16441807 ] Yu Wang commented on HBASE-20449: - [~yuzhih...@gmail.com]Thank you for reviewing. > the minimun number of region should be configurable in normalizable > --- > > Key: HBASE-20449 > URL: https://issues.apache.org/jira/browse/HBASE-20449 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0 >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20449_001.patch, HBASE-20449_002.patch > > > the minimun number of region should be configurable in normalizable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20421) HBasecontext creates a connection but does not close it
[ https://issues.apache.org/jira/browse/HBASE-20421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-20421: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) I committed v1 since the indentation is good in that patch. Thanks for the contribution, Yu. > HBasecontext creates a connection but does not close it > --- > > Key: HBASE-20421 > URL: https://issues.apache.org/jira/browse/HBASE-20421 > Project: HBase > Issue Type: Bug > Components: hbase >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Major > Labels: patch > Fix For: 3.0.0 > > Attachments: HBASE-20421.patch, HBASE-20421_master.patch, > HBASE-20421_master_1.patch, HBASE-20421_master_2.patch > > > HBasecontext creates a connection but does not turn it off -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20421) HBasecontext creates a connection but does not close it
[ https://issues.apache.org/jira/browse/HBASE-20421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-20421: --- Summary: HBasecontext creates a connection but does not close it (was: HBasecontext creates a connection but does not turn it off) > HBasecontext creates a connection but does not close it > --- > > Key: HBASE-20421 > URL: https://issues.apache.org/jira/browse/HBASE-20421 > Project: HBase > Issue Type: Bug > Components: hbase >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Major > Labels: patch > Fix For: 3.0.0 > > Attachments: HBASE-20421.patch, HBASE-20421_master.patch, > HBASE-20421_master_1.patch, HBASE-20421_master_2.patch > > > HBasecontext creates a connection but does not turn it off -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20449) the minimun number of region should be configurable in normalizable
[ https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Wang updated HBASE-20449: Attachment: HBASE-20449_002.patch > the minimun number of region should be configurable in normalizable > --- > > Key: HBASE-20449 > URL: https://issues.apache.org/jira/browse/HBASE-20449 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0 >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20449_001.patch, HBASE-20449_002.patch > > > the minimun number of region should be configurable in normalizable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20432) Cleanup related resources when remove a sync replication peer
[ https://issues.apache.org/jira/browse/HBASE-20432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441796#comment-16441796 ] Guanghao Zhang commented on HBASE-20432: As we don't have a cross-cluster procedure to handle this, so if we decide remove the remote wals dir when remove peer on remote cluster, we need add clear document for this operation. If user remove a peer in active cluster and add it back again, it will be wrong.. > Cleanup related resources when remove a sync replication peer > - > > Key: HBASE-20432 > URL: https://issues.apache.org/jira/browse/HBASE-20432 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > > When remove a sync replication peer, we should clean: > 1. the SyncReplicationState in zookeeper or table. > 2. Remote WALs & Remote WALs directory in peer clusters. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20395) Displaying thrift server type on the thrift page
[ https://issues.apache.org/jira/browse/HBASE-20395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guangxu Cheng updated HBASE-20395: -- Attachment: HBASE-20395.master.005.patch > Displaying thrift server type on the thrift page > > > Key: HBASE-20395 > URL: https://issues.apache.org/jira/browse/HBASE-20395 > Project: HBase > Issue Type: Improvement > Components: Thrift >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Major > Attachments: HBASE-20395.master.001.patch, > HBASE-20395.master.002.patch, HBASE-20395.master.003.patch, > HBASE-20395.master.004.patch, HBASE-20395.master.005.patch, > HBASE-20395.master.005.patch, result.png > > > HBase supports two types of thrift server: thrift and thrift2. > But after start the thrift server successfully, we can not get the thrift > server type conveniently. > So, displaying thrift server type on the thrift page may provide some > convenience for the users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20395) Displaying thrift server type on the thrift page
[ https://issues.apache.org/jira/browse/HBASE-20395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441791#comment-16441791 ] Guangxu Cheng commented on HBASE-20395: --- retry again. > Displaying thrift server type on the thrift page > > > Key: HBASE-20395 > URL: https://issues.apache.org/jira/browse/HBASE-20395 > Project: HBase > Issue Type: Improvement > Components: Thrift >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Major > Attachments: HBASE-20395.master.001.patch, > HBASE-20395.master.002.patch, HBASE-20395.master.003.patch, > HBASE-20395.master.004.patch, HBASE-20395.master.005.patch, > HBASE-20395.master.005.patch, result.png > > > HBase supports two types of thrift server: thrift and thrift2. > But after start the thrift server successfully, we can not get the thrift > server type conveniently. > So, displaying thrift server type on the thrift page may provide some > convenience for the users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20421) HBasecontext creates a connection but does not turn it off
[ https://issues.apache.org/jira/browse/HBASE-20421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441787#comment-16441787 ] Yu Wang commented on HBASE-20421: - In addition to indentation,there is no difference between patch v1 and v2. I don't quit understand that extracting the enclosed code into its own method ! Thanks > HBasecontext creates a connection but does not turn it off > -- > > Key: HBASE-20421 > URL: https://issues.apache.org/jira/browse/HBASE-20421 > Project: HBase > Issue Type: Bug > Components: hbase >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Major > Labels: patch > Fix For: 3.0.0 > > Attachments: HBASE-20421.patch, HBASE-20421_master.patch, > HBASE-20421_master_1.patch, HBASE-20421_master_2.patch > > > HBasecontext creates a connection but does not turn it off -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20447) Only fail cacheBlock if block collisions aren't related to next block metadata
[
https://issues.apache.org/jira/browse/HBASE-20447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441782#comment-16441782
]
Ted Yu commented on HBASE-20447:
{code}
+ * if not, throw an exception. If they are the same without the
nextBlockMetadata, return the comparison.
{code}
RuntimeException is thrown. Have you considered throwing IOE ?
{code}
+ LOG.warn("Cached block contents differ, trying to just compare the block
contents " +
+ "without the next block. CacheKey: " + cacheKey);
{code}
Is there anything admin can do after seeing the above log ?
{code}
+ LOG.warn("Cached block contents differ by nextBlockOnDiskSize.
Keeping cached block.");
+ return;
+} else {
+ LOG.warn("Cached block contents differ by nextBlockOnDiskSize.
Caching new block.");
{code}
The first part of the log is the same for both cases. Is it possible to make
the log clearer as to why the decision of caching is made ?
{code}
+if (includeNextBlockMetadata) {
+ destination.putInt(this.nextBlockOnDiskSize);
{code}
The flag only guards one field. Would includeNextBlockOnDiskSize be better name
for the parameter ?
> Only fail cacheBlock if block collisions aren't related to next block metadata
> --
>
> Key: HBASE-20447
> URL: https://issues.apache.org/jira/browse/HBASE-20447
> Project: HBase
> Issue Type: Bug
> Components: BlockCache, BucketCache
>Affects Versions: 1.4.3, 2.0.0
>Reporter: Zach York
>Assignee: Zach York
>Priority: Major
> Attachments: HBASE-20447.branch-1.001.patch
>
>
> This is the issue I was originally having here:
> [http://mail-archives.apache.org/mod_mbox/hbase-dev/201802.mbox/%3CCAN+qs_Pav=md_aoj4xji+kcnetubg2xou2ntxv1g6m8-5vn...@mail.gmail.com%3E]
>
> When we pread, we don't force the read to read all of the next block header.
> However, when we get into a race condition where two opener threads try to
> cache the same block and one thread read all of the next block header and the
> other one didn't, it will fail the open process. This is especially important
> in a splitting case where it will potentially fail the split process.
> Instead, in the caches, we should only fail if the required blocks are
> different.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20442) clean up incorrect use of commons-collections 3
[
https://issues.apache.org/jira/browse/HBASE-20442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441771#comment-16441771
]
Hadoop QA commented on HBASE-20442:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
20s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
57s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
37s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
51s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
50s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
33s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{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} 3m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
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} 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
50s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
17m 10s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
57s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
35s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
11s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
50s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}147m 34s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 14m
6s{color} | {color:green} hbase-backup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
34s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}235m 7s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20442 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12919491/HBASE-20442.0.patch |
| Optional
[jira] [Commented] (HBASE-20449) the minimun number of region should be configurable in normalizable
[
https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441768#comment-16441768
]
Ted Yu commented on HBASE-20449:
{code}
26 import org.apache.hadoop.hbase.*;
{code}
No wildcard import.
{code}
+ public int getMinRegionCount(){
+return configuration.getInt("hbase.min.region.count",3);
{code}
You can retrieve the min region count in constructor and save as instance
variable.
w.r.t. the config key name, please include normalizer in it.
> the minimun number of region should be configurable in normalizable
> ---
>
> Key: HBASE-20449
> URL: https://issues.apache.org/jira/browse/HBASE-20449
> Project: HBase
> Issue Type: Improvement
> Components: hbase
>Affects Versions: 3.0.0
>Reporter: Yu Wang
>Assignee: Yu Wang
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: HBASE-20449_001.patch
>
>
> the minimun number of region should be configurable in normalizable
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20378) Provide a hbck option to cleanup replication barrier for a table
[ https://issues.apache.org/jira/browse/HBASE-20378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-20378: - Fix Version/s: 3.0.0 Affects Version/s: 3.0.0 Status: Patch Available (was: Open) > Provide a hbck option to cleanup replication barrier for a table > > > Key: HBASE-20378 > URL: https://issues.apache.org/jira/browse/HBASE-20378 > Project: HBase > Issue Type: Sub-task >Affects Versions: 3.0.0 >Reporter: Duo Zhang >Assignee: Jingyun Tian >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20378.master.001.patch > > > It is not easy to deal with the scenario where a user change the replication > scope from global to local since it may change the scope back while we are > cleaning in the background. And I think this a rare operation so just provide > an hbck option to deal with it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20449) the minimun number of region should be configurable in normalizable
[ https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Wang updated HBASE-20449: Attachment: HBASE-20449_001.patch > the minimun number of region should be configurable in normalizable > --- > > Key: HBASE-20449 > URL: https://issues.apache.org/jira/browse/HBASE-20449 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0 >Reporter: Yu Wang >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20449_001.patch > > > the minimun number of region should be configurable in normalizable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20449) the minimun number of region should be configurable in normalizable
[ https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Wang updated HBASE-20449: Status: Patch Available (was: Open) > the minimun number of region should be configurable in normalizable > --- > > Key: HBASE-20449 > URL: https://issues.apache.org/jira/browse/HBASE-20449 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0 >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20449_001.patch > > > the minimun number of region should be configurable in normalizable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HBASE-20449) the minimun number of region should be configurable in normalizable
[ https://issues.apache.org/jira/browse/HBASE-20449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Wang reassigned HBASE-20449: --- Assignee: Yu Wang > the minimun number of region should be configurable in normalizable > --- > > Key: HBASE-20449 > URL: https://issues.apache.org/jira/browse/HBASE-20449 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0 >Reporter: Yu Wang >Assignee: Yu Wang >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20449_001.patch > > > the minimun number of region should be configurable in normalizable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20449) the minimun number of region should be configurable in normalizable
Yu Wang created HBASE-20449: --- Summary: the minimun number of region should be configurable in normalizable Key: HBASE-20449 URL: https://issues.apache.org/jira/browse/HBASE-20449 Project: HBase Issue Type: Improvement Components: hbase Affects Versions: 3.0.0 Reporter: Yu Wang Fix For: 3.0.0 the minimun number of region should be configurable in normalizable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20432) Cleanup related resources when remove a sync replication peer
[ https://issues.apache.org/jira/browse/HBASE-20432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441753#comment-16441753 ] Zheng Hu commented on HBASE-20432: -- bq. The remote wals on the remote cluster can be removed when we remove the sync replication peer on remote cluster ? Sound reasonable. Will upload patch for this issue. > Cleanup related resources when remove a sync replication peer > - > > Key: HBASE-20432 > URL: https://issues.apache.org/jira/browse/HBASE-20432 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > > When remove a sync replication peer, we should clean: > 1. the SyncReplicationState in zookeeper or table. > 2. Remote WALs & Remote WALs directory in peer clusters. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20439) Clean up incorrect use of commons-logging in hbase-server
[
https://issues.apache.org/jira/browse/HBASE-20439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441739#comment-16441739
]
Sean Busbey commented on HBASE-20439:
-
-v1
- rebased to current master
- fixed checkstyle complaint.
> Clean up incorrect use of commons-logging in hbase-server
> -
>
> Key: HBASE-20439
> URL: https://issues.apache.org/jira/browse/HBASE-20439
> Project: HBase
> Issue Type: Bug
> Components: dependencies, logging
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Fix For: 2.0.1
>
> Attachments: HBASE-20439.0.patch, HBASE-20439.1.patch
>
>
> We moved to slf4j in HBASE-10092, but looking at our source tree we've had
> some regression back to commons-logging:
> {code}
> $ git grep -E "org.apache.commons.logging.Log(Factory|;)"
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/zksyncer/ClientZKSyncer.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/zksyncer/ClientZKSyncer.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierImpl.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierImpl.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/RegionSizeReportingChore.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/RegionSizeReportingChore.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/RegionSizeStoreImpl.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/RegionSizeStoreImpl.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/throttle/StoreHotnessProtector.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/throttle/StoreHotnessProtector.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/TestClusterPortAssignment.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/TestClusterPortAssignment.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFlushFromClient.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFlushFromClient.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestSeparateClientZKCluster.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestSeparateClientZKCluster.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/procedure/TestFailedProcCleanup.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/procedure/TestFailedProcCleanup.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/wal/TestDisabledWAL.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/wal/TestDisabledWAL.java:import
> org.apache.commons.logging.LogFactory;
> {code}
> replace with slf4j
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20439) Clean up incorrect use of commons-logging in hbase-server
[
https://issues.apache.org/jira/browse/HBASE-20439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-20439:
Attachment: HBASE-20439.1.patch
> Clean up incorrect use of commons-logging in hbase-server
> -
>
> Key: HBASE-20439
> URL: https://issues.apache.org/jira/browse/HBASE-20439
> Project: HBase
> Issue Type: Bug
> Components: dependencies, logging
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Fix For: 2.0.1
>
> Attachments: HBASE-20439.0.patch, HBASE-20439.1.patch
>
>
> We moved to slf4j in HBASE-10092, but looking at our source tree we've had
> some regression back to commons-logging:
> {code}
> $ git grep -E "org.apache.commons.logging.Log(Factory|;)"
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/zksyncer/ClientZKSyncer.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/zksyncer/ClientZKSyncer.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierImpl.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierImpl.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/RegionSizeReportingChore.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/RegionSizeReportingChore.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/RegionSizeStoreImpl.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/RegionSizeStoreImpl.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/throttle/StoreHotnessProtector.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/throttle/StoreHotnessProtector.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/TestClusterPortAssignment.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/TestClusterPortAssignment.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFlushFromClient.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFlushFromClient.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestSeparateClientZKCluster.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestSeparateClientZKCluster.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/procedure/TestFailedProcCleanup.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/procedure/TestFailedProcCleanup.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/wal/TestDisabledWAL.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/wal/TestDisabledWAL.java:import
> org.apache.commons.logging.LogFactory;
> {code}
> replace with slf4j
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20448) update ref guide to expressly use shaded clients for examples
Sean Busbey created HBASE-20448: --- Summary: update ref guide to expressly use shaded clients for examples Key: HBASE-20448 URL: https://issues.apache.org/jira/browse/HBASE-20448 Project: HBase Issue Type: Sub-task Components: Client, documentation, mapreduce Reporter: Sean Busbey the whole mapreduce section, especially, should be using the shaded version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19924) hbase rpc throttling does not work for multi() with request count rater.
[
https://issues.apache.org/jira/browse/HBASE-19924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441728#comment-16441728
]
Hadoop QA commented on HBASE-19924:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
22s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
44s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{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
46s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 23s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}148m 2s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
26s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}194m 32s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-19924 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12919482/HBASE-19924-master-v002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 5d04d52c0fca 3.13.0-137-generic #186-Ubuntu SMP Mon Dec 4
19:09:19 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 / 357a089e06 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/12507/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12507/testReport/ |
| Max. process+thread count | 3799 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12507/console |
| Powered by | Apache
[jira] [Commented] (HBASE-20151) Bug with SingleColumnValueFilter and FamilyFilter
[
https://issues.apache.org/jira/browse/HBASE-20151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441724#comment-16441724
]
Hadoop QA commented on HBASE-20151:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
28s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
58s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
51s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
48s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
32s{color} | {color:green} hbase-client: The patch generated 0 new + 154
unchanged - 1 fixed = 154 total (was 155) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
16s{color} | {color:green} The patch hbase-server passed checkstyle {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
17s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
14m 51s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
52s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}105m
5s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
40s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}160m 34s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20151 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12919492/HBASE-20151.master.004.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux e68e25c0573f 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HBASE-20440) Clean up incorrect use of commons-lang 2.y
[
https://issues.apache.org/jira/browse/HBASE-20440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441722#comment-16441722
]
Hadoop QA commented on HBASE-20440:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
12s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
56s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
2s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
56s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
51s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
38s{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
53s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 32s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
25s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}126m
26s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
41s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}182m 8s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20440 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12919485/HBASE-20440.0.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 88b65a946066 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 357a089e06 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs |
[jira] [Commented] (HBASE-18792) hbase-2 needs to defend against hbck operations
[
https://issues.apache.org/jira/browse/HBASE-18792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441721#comment-16441721
]
Hadoop QA commented on HBASE-18792:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
56s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
55s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
50s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
19s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 31s{color}
| {color:red} hbase-common generated 1 new + 40 unchanged - 2 fixed = 41 total
(was 42) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
25s{color} | {color:green} hbase-common: The patch generated 0 new + 1
unchanged - 2 fixed = 1 total (was 3) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
11s{color} | {color:red} hbase-server: The patch generated 5 new + 94 unchanged
- 3 fixed = 99 total (was 97) {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
57s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 27s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
51s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
26s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}126m
21s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
42s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}181m 58s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-18792 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12919487/hbase-18792.master.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
|
[jira] [Updated] (HBASE-20447) Only fail cacheBlock if block collisions aren't related to next block metadata
[ https://issues.apache.org/jira/browse/HBASE-20447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zach York updated HBASE-20447: -- Attachment: HBASE-20447.branch-1.001.patch > Only fail cacheBlock if block collisions aren't related to next block metadata > -- > > Key: HBASE-20447 > URL: https://issues.apache.org/jira/browse/HBASE-20447 > Project: HBase > Issue Type: Bug > Components: BlockCache, BucketCache >Affects Versions: 1.4.3, 2.0.0 >Reporter: Zach York >Assignee: Zach York >Priority: Major > Attachments: HBASE-20447.branch-1.001.patch > > > This is the issue I was originally having here: > [http://mail-archives.apache.org/mod_mbox/hbase-dev/201802.mbox/%3CCAN+qs_Pav=md_aoj4xji+kcnetubg2xou2ntxv1g6m8-5vn...@mail.gmail.com%3E] > > When we pread, we don't force the read to read all of the next block header. > However, when we get into a race condition where two opener threads try to > cache the same block and one thread read all of the next block header and the > other one didn't, it will fail the open process. This is especially important > in a splitting case where it will potentially fail the split process. > Instead, in the caches, we should only fail if the required blocks are > different. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20447) Only fail cacheBlock if block collisions aren't related to next block metadata
Zach York created HBASE-20447: - Summary: Only fail cacheBlock if block collisions aren't related to next block metadata Key: HBASE-20447 URL: https://issues.apache.org/jira/browse/HBASE-20447 Project: HBase Issue Type: Bug Components: BlockCache, BucketCache Affects Versions: 1.4.3, 2.0.0 Reporter: Zach York Assignee: Zach York This is the issue I was originally having here: [http://mail-archives.apache.org/mod_mbox/hbase-dev/201802.mbox/%3CCAN+qs_Pav=md_aoj4xji+kcnetubg2xou2ntxv1g6m8-5vn...@mail.gmail.com%3E] When we pread, we don't force the read to read all of the next block header. However, when we get into a race condition where two opener threads try to cache the same block and one thread read all of the next block header and the other one didn't, it will fail the open process. This is especially important in a splitting case where it will potentially fail the split process. Instead, in the caches, we should only fail if the required blocks are different. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20188) [TESTING] Performance
[ https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441683#comment-16441683 ] stack commented on HBASE-20188: --- I tried enabling YCSB clientSideBuffering, see https://github.com/brianfrankcooper/YCSB/issues/1136, but it made the regionserver go into GC hell. Default buffer size is 12MB. Setting it to 2MB made it so the test would pass. I see that 1.2.7 is better at writing and its a wash when mixed or read-only. I do see an instance of memstore bloat as @anoop talks of above.Will be back w/ detail. > [TESTING] Performance > - > > Key: HBASE-20188 > URL: https://issues.apache.org/jira/browse/HBASE-20188 > Project: HBase > Issue Type: Umbrella > Components: Performance >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 2.0.0 > > Attachments: CAM-CONFIG-V01.patch, HBASE-20188-xac.sh, > HBASE-20188.sh, HBase 2.0 performance evaluation - 8GB(1).pdf, HBase 2.0 > performance evaluation - 8GB.pdf, HBase 2.0 performance evaluation - Basic vs > None_ system settings.pdf, ITBLL2.5B_1.2.7vs2.0.0_cpu.png, > ITBLL2.5B_1.2.7vs2.0.0_gctime.png, ITBLL2.5B_1.2.7vs2.0.0_iops.png, > ITBLL2.5B_1.2.7vs2.0.0_load.png, ITBLL2.5B_1.2.7vs2.0.0_memheap.png, > ITBLL2.5B_1.2.7vs2.0.0_memstore.png, ITBLL2.5B_1.2.7vs2.0.0_ops.png, > ITBLL2.5B_1.2.7vs2.0.0_ops_NOT_summing_regions.png, YCSB_CPU.png, > YCSB_GC_TIME.png, YCSB_IN_MEMORY_COMPACTION=NONE.ops.png, YCSB_MEMSTORE.png, > YCSB_OPs.png, YCSB_in-memory-compaction=NONE.ops.png, YCSB_load.png, > flamegraph-1072.1.svg, flamegraph-1072.2.svg, hbase-env.sh, hbase-site.xml, > hbase-site.xml, hits.png, lock.127.workloadc.20180402T200918Z.svg, > lock.2.memsize2.c.20180403T160257Z.svg, perregion.png, run_ycsb.sh, > total.png, tree.txt, workloadx, workloadx > > > How does 2.0.0 compare to old versions? Is it faster, slower? There is rumor > that it is much slower, that the problem is the asyncwal writing. Does > in-memory compaction slow us down or speed us up? What happens when you > enable offheaping? > Keep notes here in this umbrella issue. Need to be able to say something > about perf when 2.0.0 ships. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20244) NoSuchMethodException when retrieving private method decryptEncryptedDataEncryptionKey from DFSClient
[
https://issues.apache.org/jira/browse/HBASE-20244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441676#comment-16441676
]
stack commented on HBASE-20244:
---
[~jojochuang] Thanks for the help and good question. Is there a way to ask the
fs if its at-rest encrypted? There is also HBASE-20403 where offset calcs done
in hbase break if the underlying hdfs is setup in encrypt at rest. Thanks.
> NoSuchMethodException when retrieving private method
> decryptEncryptedDataEncryptionKey from DFSClient
> -
>
> Key: HBASE-20244
> URL: https://issues.apache.org/jira/browse/HBASE-20244
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 20244.v1.txt, 20244.v1.txt, 20244.v1.txt
>
>
> I was running unit test against hadoop 3.0.1 RC and saw the following in test
> output:
> {code}
> ERROR [RS-EventLoopGroup-3-3]
> asyncfs.FanOutOneBlockAsyncDFSOutputSaslHelper(267): Couldn't properly
> initialize access to HDFS internals. Please update your WAL Provider to not
> make use of the 'asyncfs' provider. See HBASE-16110 for more information.
> java.lang.NoSuchMethodException:
> org.apache.hadoop.hdfs.DFSClient.decryptEncryptedDataEncryptionKey(org.apache.hadoop.fs.FileEncryptionInfo)
> at java.lang.Class.getDeclaredMethod(Class.java:2130)
> at
> org.apache.hadoop.hbase.io.asyncfs.FanOutOneBlockAsyncDFSOutputSaslHelper.createTransparentCryptoHelper(FanOutOneBlockAsyncDFSOutputSaslHelper.java:232)
> at
> org.apache.hadoop.hbase.io.asyncfs.FanOutOneBlockAsyncDFSOutputSaslHelper.(FanOutOneBlockAsyncDFSOutputSaslHelper.java:262)
> at
> org.apache.hadoop.hbase.io.asyncfs.FanOutOneBlockAsyncDFSOutputHelper.initialize(FanOutOneBlockAsyncDFSOutputHelper.java:661)
> at
> org.apache.hadoop.hbase.io.asyncfs.FanOutOneBlockAsyncDFSOutputHelper.access$300(FanOutOneBlockAsyncDFSOutputHelper.java:118)
> at
> org.apache.hadoop.hbase.io.asyncfs.FanOutOneBlockAsyncDFSOutputHelper$13.operationComplete(FanOutOneBlockAsyncDFSOutputHelper.java:720)
> at
> org.apache.hadoop.hbase.io.asyncfs.FanOutOneBlockAsyncDFSOutputHelper$13.operationComplete(FanOutOneBlockAsyncDFSOutputHelper.java:715)
> at
> org.apache.hbase.thirdparty.io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:507)
> at
> org.apache.hbase.thirdparty.io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:500)
> at
> org.apache.hbase.thirdparty.io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:479)
> at
> org.apache.hbase.thirdparty.io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:420)
> at
> org.apache.hbase.thirdparty.io.netty.util.concurrent.DefaultPromise.trySuccess(DefaultPromise.java:104)
> at
> org.apache.hbase.thirdparty.io.netty.channel.DefaultChannelPromise.trySuccess(DefaultChannelPromise.java:82)
> at
> org.apache.hbase.thirdparty.io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.fulfillConnectPromise(AbstractNioChannel.java:306)
> at
> org.apache.hbase.thirdparty.io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:341)
> at
> org.apache.hbase.thirdparty.io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:633)
> at
> org.apache.hbase.thirdparty.io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
> {code}
> The private method was moved by HDFS-12574 to HdfsKMSUtil with different
> signature.
> To accommodate the above method movement, it seems we need to call the
> following method of DFSClient :
> {code}
> public KeyProvider getKeyProvider() throws IOException {
> {code}
> Since the new decryptEncryptedDataEncryptionKey method has this signature:
> {code}
> static KeyVersion decryptEncryptedDataEncryptionKey(FileEncryptionInfo
> feInfo, KeyProvider keyProvider) throws IOException {
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20411) Ameliorate MutableSegment synchronize
[ https://issues.apache.org/jira/browse/HBASE-20411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441674#comment-16441674 ] stack commented on HBASE-20411: --- This report shows this patch making writes 10% slower: https://docs.google.com/spreadsheets/d/1w2NBqAPFthG8Ib4C0pHpLARYpWoIF2Vck2vHZW77zE4/edit#gid=718132069 Needs work. > Ameliorate MutableSegment synchronize > - > > Key: HBASE-20411 > URL: https://issues.apache.org/jira/browse/HBASE-20411 > Project: HBase > Issue Type: Bug >Reporter: stack >Priority: Major > Attachments: 2.load.patched.17704.lock.svg, > 2.load.patched.2.17704.lock.svg, 2.more.patch.12010.lock.svg, 41901.lock.svg, > HBASE-20411.branch-2.0.001.patch, HBASE-20411.branch-2.0.002.patch, > HBASE-20411.branch-2.0.003.patch, HBASE-20411.branch-2.0.004.patch, > HBASE-20411.branch-2.0.005.patch, HBASE-20411.branch-2.0.006.patch, > HBASE-20411.branch-2.0.007.patch > > > This item is migrated from HBASE-20236 so it gets dedicated issue. > Let me upload evidence that has this synchronize as a stake in our write-time > perf. I'll migrate the patch I posted with updates that come of comments > posted by [~mdrob] on the HBASE-20236 issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20209) Do Not Use Both Map containsKey and get Methods
[
https://issues.apache.org/jira/browse/HBASE-20209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441665#comment-16441665
]
Hadoop QA commented on HBASE-20209:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
32s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
13s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
1s{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
19s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
13m 10s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}159m 18s{color}
| {color:red} hbase-server 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}200m 41s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20209 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12919469/HBASE-20209.2.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux d37689210470 4.4.0-89-generic #112-Ubuntu SMP Mon Jul 31
19:38:41 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 / 357a089e06 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/12504/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12504/testReport/ |
| Max. process+thread count | 4244 (vs. ulimit of 1) |
| modules | C: hbase-server U:
[jira] [Updated] (HBASE-20446) Allow building HBase 1.x against Hadoop 3.1.0
[ https://issues.apache.org/jira/browse/HBASE-20446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-20446: -- Priority: Minor (was: Major) > Allow building HBase 1.x against Hadoop 3.1.0 > - > > Key: HBASE-20446 > URL: https://issues.apache.org/jira/browse/HBASE-20446 > Project: HBase > Issue Type: Improvement >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl >Priority: Minor > Fix For: 1.5.0 > > Attachments: 20446.txt > > > Simple change, just leaving it here in case somebody needs this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20446) Allow building HBase 1.x against Hadoop 3.1.0
[ https://issues.apache.org/jira/browse/HBASE-20446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-20446: -- Fix Version/s: 1.5.0 > Allow building HBase 1.x against Hadoop 3.1.0 > - > > Key: HBASE-20446 > URL: https://issues.apache.org/jira/browse/HBASE-20446 > Project: HBase > Issue Type: Improvement >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl >Priority: Major > Fix For: 1.5.0 > > Attachments: 20446.txt > > > Simple change, just leaving it here in case somebody needs this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20446) Allow building HBase 1.x against Hadoop 3.1.0
[ https://issues.apache.org/jira/browse/HBASE-20446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-20446: -- Description: Simple change, just leaving it here in case somebody needs this. > Allow building HBase 1.x against Hadoop 3.1.0 > - > > Key: HBASE-20446 > URL: https://issues.apache.org/jira/browse/HBASE-20446 > Project: HBase > Issue Type: Improvement >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl >Priority: Major > Attachments: 20446.txt > > > Simple change, just leaving it here in case somebody needs this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20446) Allow building HBase 1.x against Hadoop 3.1.0
Lars Hofhansl created HBASE-20446: - Summary: Allow building HBase 1.x against Hadoop 3.1.0 Key: HBASE-20446 URL: https://issues.apache.org/jira/browse/HBASE-20446 Project: HBase Issue Type: Improvement Reporter: Lars Hofhansl Assignee: Lars Hofhansl Attachments: 20446.txt -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20446) Allow building HBase 1.x against Hadoop 3.1.0
[ https://issues.apache.org/jira/browse/HBASE-20446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-20446: -- Attachment: 20446.txt > Allow building HBase 1.x against Hadoop 3.1.0 > - > > Key: HBASE-20446 > URL: https://issues.apache.org/jira/browse/HBASE-20446 > Project: HBase > Issue Type: Improvement >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl >Priority: Major > Attachments: 20446.txt > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19994) Create a new class for RPC throttling exception, make it retryable.
[
https://issues.apache.org/jira/browse/HBASE-19994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441654#comment-16441654
]
Hudson commented on HBASE-19994:
Results for branch branch-2.0
[build #189 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Create a new class for RPC throttling exception, make it retryable.
>
>
> Key: HBASE-19994
> URL: https://issues.apache.org/jira/browse/HBASE-19994
> Project: HBase
> Issue Type: Improvement
>Reporter: huaxiang sun
>Assignee: huaxiang sun
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-19994-master-v01.patch,
> HBASE-19994-master-v02.patch, HBASE-19994-master-v03.patch,
> HBASE-19994-master-v04.patch, HBASE-19994-master-v05.patch,
> HBASE-19994-master-v06.patch, HBASE-19994-master-v07.patch
>
>
> Based on a discussion at dev mailing list.
>
> {code:java}
> Thanks Andrew.
> +1 for the second option, I will create a jira for this change.
> Huaxiang
> On Feb 9, 2018, at 1:09 PM, Andrew Purtell wrote:
> We have
> public class ThrottlingException extends QuotaExceededException
> public class QuotaExceededException extends DoNotRetryIOException
> Let the storage quota limits throw QuotaExceededException directly (based
> on DNRIOE). That seems fine.
> However, ThrottlingException is thrown as a result of a temporal quota,
> so it is inappropriate for this to inherit from DNRIOE, it should inherit
> IOException instead so the client is allowed to retry until successful, or
> until the retry policy is exhausted.
> We are in a bit of a pickle because we've released with this inheritance
> hierarchy, so to change it we will need a new minor, or we will want to
> deprecate ThrottlingException and use a new exception class instead, one
> which does not inherit from DNRIOE.
> On Feb 7, 2018, at 9:25 AM, Huaxiang Sun wrote:
> Hi Mike,
> You are right. For rpc throttling, definitely it is retryable. For storage
> quota, I think it will be fail faster (non-retryable).
> We probably need to separate these two types of exceptions, I will do some
> more research and follow up.
> Thanks,
> Huaxiang
> On Feb 7, 2018, at 9:16 AM, Mike Drob wrote:
> I think, philosophically, there can be two kinds of QEE -
> For throttling, we can retry. The quota is a temporal quota - you have done
> too many operations this minute, please try again next minute and
> everything will work.
> For storage, we shouldn't retry. The quota is a fixed quote - you have
> exceeded your allotted disk space, please do not try again until you have
> remedied the situation.
> Our current usage conflates the two, sometimes it is correct, sometimes not.
> On Wed, Feb 7, 2018 at 11:00 AM, Huaxiang Sun wrote:
> Hi Stack,
> I run into a case that a mapreduce job in hive cannot finish because
> it runs into a QEE.
> I need to look into the hive mr task to see if QEE is not handled
> correctly in hbase code or in hive code.
> I am thinking that if QEE is a retryable exception, then it should be
> taken care of by the hbase code.
> I will check more and report back.
> Thanks,
> Huaxiang
> On Feb 7, 2018, at 8:23 AM, Stack wrote:
> QEE being a DNRIOE seems right on the face of it.
> But if throttling, a DNRIOE is inappropriate. Where you seeing a QEE in a
> throttling scenario Huaxiang?
> Thanks,
> S
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20399) Fix merge layout
[
https://issues.apache.org/jira/browse/HBASE-20399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441651#comment-16441651
]
Hudson commented on HBASE-20399:
Results for branch branch-2.0
[build #189 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Fix merge layout
>
>
> Key: HBASE-20399
> URL: https://issues.apache.org/jira/browse/HBASE-20399
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 3.0.0, 2.0.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-20399.master.001.patch, after.png, merge.png
>
>
> Merge regions on {{table.jsp}} has wrong layout (see screenshot).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20404) Ugly cleanerchore complaint that dir is not empty
[
https://issues.apache.org/jira/browse/HBASE-20404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441653#comment-16441653
]
Hudson commented on HBASE-20404:
Results for branch branch-2.0
[build #189 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Ugly cleanerchore complaint that dir is not empty
> -
>
> Key: HBASE-20404
> URL: https://issues.apache.org/jira/browse/HBASE-20404
> Project: HBase
> Issue Type: Bug
> Components: master
>Affects Versions: 1.4.4, 2.0.0
>Reporter: stack
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.4.4, 2.0.1
>
> Attachments: HBASE-20404.0.patch, HBASE-20404.1.patch,
> HBASE-20404.2.patch
>
>
> I see these big dirty exceptions in my master log during a long-run Lets
> clean them up (Are they exceptions I as an operator can actually do something
> about? Are they 'problems'? Should they be LOG.warn?)
> {code}
> 2018-04-12 16:02:09,911 WARN [ForkJoinPool-1-worker-15]
> cleaner.CleanerChore: Could not delete dir under
> hdfs://ve0524.halxg.cloudera.com:8020/hbase/archive/data/default/IntegrationTestBigLinkedList/1e24549061df3adc4858fbcaf1929553/meta;
> {}
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.fs.PathIsNotEmptyDirectoryException):
>
> `/hbase/archive/data/default/IntegrationTestBigLinkedList/1e24549061df3adc4858fbcaf1929553/meta
> is non empty': Directory is not empty
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirDeleteOp.delete(FSDirDeleteOp.java:115)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.delete(FSNamesystem.java:2848)
> at
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.delete(NameNodeRpcServer.java:1048)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.delete(ClientNamenodeProtocolServerSideTranslatorPB.java:641)
> at
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:447)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:989)
> at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:847)
> at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:790)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1836)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2486)
> at org.apache.hadoop.ipc.Client.getRpcResponse(Client.java:1489)
> at org.apache.hadoop.ipc.Client.call(Client.java:1435)
> at org.apache.hadoop.ipc.Client.call(Client.java:1345)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:227)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:116)
> at com.sun.proxy.$Proxy26.delete(Unknown Source)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.delete(ClientNamenodeProtocolTranslatorPB.java:568)
> at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:409)
> at
> org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeMethod(RetryInvocationHandler.java:163)
> at
> org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invoke(RetryInvocationHandler.java:155)
> at
> org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeOnce(RetryInvocationHandler.java:95)
> at
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:346)
> at com.sun.proxy.$Proxy27.delete(Unknown Source)
> at
[jira] [Commented] (HBASE-20398) Redirect doesn't work on web UI
[
https://issues.apache.org/jira/browse/HBASE-20398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441652#comment-16441652
]
Hudson commented on HBASE-20398:
Results for branch branch-2.0
[build #189 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/189//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Redirect doesn't work on web UI
> ---
>
> Key: HBASE-20398
> URL: https://issues.apache.org/jira/browse/HBASE-20398
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 3.0.0, 2.0.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20398.master.001.patch
>
>
> {{table.jsp}} contains _"Go Back, or wait for the redirect."_ string after we
> invoke compaction, split, etc. Previously it redirected to the previous page
> after 5 seconds. The string is there currently, but nothing happens.
> After digging into the code, a found the following:
> - {{ecce7c2}} (HBASE-3948) it was introduced,
> - {{3bd9191}} (HBASE-9850) it was refactored,
> - {{3b2b22b}} (HBASE-19291) it was removed.
> This string appears on {{rsgroup.jsp}}, {{snapshot.jsp}} and {{table.jsp}}.
> We should fix them by removing the string, or by adding redirection again.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20293) get_splits returns duplicate split points when region replication is on
[
https://issues.apache.org/jira/browse/HBASE-20293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441635#comment-16441635
]
huaxiang sun commented on HBASE-20293:
--
[~brfrn169], I committed the patch to hbase-2.0.0+. Can you post a patch for
branch-1? Thanks.
> get_splits returns duplicate split points when region replication is on
> ---
>
> Key: HBASE-20293
> URL: https://issues.apache.org/jira/browse/HBASE-20293
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Minor
> Attachments: HBASE-20293.master.001.patch,
> HBASE-20293.master.002.patch, HBASE-20293.master.003.patch,
> HBASE-20293.master.004.patch
>
>
> When region replication is on, get_splits returns duplicate split points like
> the following:
> {code}
> hbase(main):001:0> create "test", "cf", {REGION_REPLICATION => 3}, SPLITS =>
> ["10"]
> Created table test
> Took 1.0975 seconds
> hbase(main):002:0> get_splits "test"
> Total number of splits = 4
> 10
> 10
> 10
> Took 0.0941 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20214) Review of RegionLocationFinder Class
[ https://issues.apache.org/jira/browse/HBASE-20214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441619#comment-16441619 ] BELUGA BEHR commented on HBASE-20214: - [~yuzhih...@gmail.com] Try again? :) > Review of RegionLocationFinder Class > > > Key: HBASE-20214 > URL: https://issues.apache.org/jira/browse/HBASE-20214 > Project: HBase > Issue Type: Improvement > Components: Balancer, master >Affects Versions: 2.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Minor > Attachments: HBASE-20214.1.patch, HBASE-20214.2.patch, > HBASE-20214.3.patch > > > # Use SLF4J parameter logging > # Remove superfluous code > # Replace code with re-usable libraries where possible > # Use different data structure > # Small perf improvements > # Fix some checkstyle -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20439) Clean up incorrect use of commons-logging in hbase-server
[
https://issues.apache.org/jira/browse/HBASE-20439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441602#comment-16441602
]
Hadoop QA commented on HBASE-20439:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 5 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
12s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
41s{color} | {color:green} master passed {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
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
32s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
58s{color} | {color:red} hbase-server: The patch generated 1 new + 1 unchanged
- 0 fixed = 2 total (was 1) {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
17s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
12m 54s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}104m
25s{color} | {color:green} hbase-server in the patch passed. {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}144m 47s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20439 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12919474/HBASE-20439.0.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux b1a002f69304 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 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 / 357a089e06 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/12503/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12503/testReport/ |
| Max. process+thread count | 5379 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
[jira] [Commented] (HBASE-20214) Review of RegionLocationFinder Class
[
https://issues.apache.org/jira/browse/HBASE-20214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441601#comment-16441601
]
Hadoop QA commented on HBASE-20214:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
38s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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} 8m
5s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
47s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
54s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
39s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} hbase-server: The patch generated 0 new + 1
unchanged - 2 fixed = 1 total (was 3) {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
51s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 12s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
12s{color} | {color:green} the patch passed {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:green}+1{color} | {color:green} unit {color} | {color:green}137m
41s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
25s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}188m 15s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20214 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12919468/HBASE-20214.3.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux b87038dbed69 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 357a089e06 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12502/testReport/ |
| Max. process+thread count | 4184 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
[jira] [Commented] (HBASE-20436) IntegrationTestSparkBulkLoad cannot access abstract processOptions of AbstractHBaseTool
[
https://issues.apache.org/jira/browse/HBASE-20436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441594#comment-16441594
]
Ted Yu commented on HBASE-20436:
No.
bq. Caused by: java.lang.IllegalArgumentException: port out of range:-1
The above was fixed by addendum to HBASE-20244
> IntegrationTestSparkBulkLoad cannot access abstract processOptions of
> AbstractHBaseTool
> ---
>
> Key: HBASE-20436
> URL: https://issues.apache.org/jira/browse/HBASE-20436
> Project: HBase
> Issue Type: Bug
> Components: spark
>Reporter: Ted Yu
>Priority: Major
>
> Saw the following compilation error in hbase-spark-it module:
> {code}
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /hbase/hbase-spark-it/src/test/java/org/apache/hadoop/hbase/spark/IntegrationTestSparkBulkLoad.java:[638,10]
> abstract method
> processOptions(org.apache.hbase.thirdparty.org.apache.commons.cli.CommandLine)
> in org.apache.hadoop.hbase.util.AbstractHBaseTool cannot be accessed directly
> {code}
> The processOptions method of AbstractHBaseTool is abstract.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20436) IntegrationTestSparkBulkLoad cannot access abstract processOptions of AbstractHBaseTool
[
https://issues.apache.org/jira/browse/HBASE-20436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441594#comment-16441594
]
Ted Yu edited comment on HBASE-20436 at 4/17/18 10:22 PM:
--
No.
bq. Caused by: java.lang.IllegalArgumentException: port out of range:-1
The above was fixed by addendum to HBASE-20224
was (Author: yuzhih...@gmail.com):
No.
bq. Caused by: java.lang.IllegalArgumentException: port out of range:-1
The above was fixed by addendum to HBASE-20244
> IntegrationTestSparkBulkLoad cannot access abstract processOptions of
> AbstractHBaseTool
> ---
>
> Key: HBASE-20436
> URL: https://issues.apache.org/jira/browse/HBASE-20436
> Project: HBase
> Issue Type: Bug
> Components: spark
>Reporter: Ted Yu
>Priority: Major
>
> Saw the following compilation error in hbase-spark-it module:
> {code}
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /hbase/hbase-spark-it/src/test/java/org/apache/hadoop/hbase/spark/IntegrationTestSparkBulkLoad.java:[638,10]
> abstract method
> processOptions(org.apache.hbase.thirdparty.org.apache.commons.cli.CommandLine)
> in org.apache.hadoop.hbase.util.AbstractHBaseTool cannot be accessed directly
> {code}
> The processOptions method of AbstractHBaseTool is abstract.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20436) IntegrationTestSparkBulkLoad cannot access abstract processOptions of AbstractHBaseTool
[
https://issues.apache.org/jira/browse/HBASE-20436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441590#comment-16441590
]
Wei-Chiu Chuang commented on HBASE-20436:
-
Is it a dup of HBASE-20336?
> IntegrationTestSparkBulkLoad cannot access abstract processOptions of
> AbstractHBaseTool
> ---
>
> Key: HBASE-20436
> URL: https://issues.apache.org/jira/browse/HBASE-20436
> Project: HBase
> Issue Type: Bug
> Components: spark
>Reporter: Ted Yu
>Priority: Major
>
> Saw the following compilation error in hbase-spark-it module:
> {code}
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /hbase/hbase-spark-it/src/test/java/org/apache/hadoop/hbase/spark/IntegrationTestSparkBulkLoad.java:[638,10]
> abstract method
> processOptions(org.apache.hbase.thirdparty.org.apache.commons.cli.CommandLine)
> in org.apache.hadoop.hbase.util.AbstractHBaseTool cannot be accessed directly
> {code}
> The processOptions method of AbstractHBaseTool is abstract.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20293) get_splits returns duplicate split points when region replication is on
[
https://issues.apache.org/jira/browse/HBASE-20293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441588#comment-16441588
]
huaxiang sun commented on HBASE-20293:
--
I will commit, thanks for the reviews.
> get_splits returns duplicate split points when region replication is on
> ---
>
> Key: HBASE-20293
> URL: https://issues.apache.org/jira/browse/HBASE-20293
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Minor
> Attachments: HBASE-20293.master.001.patch,
> HBASE-20293.master.002.patch, HBASE-20293.master.003.patch,
> HBASE-20293.master.004.patch
>
>
> When region replication is on, get_splits returns duplicate split points like
> the following:
> {code}
> hbase(main):001:0> create "test", "cf", {REGION_REPLICATION => 3}, SPLITS =>
> ["10"]
> Created table test
> Took 1.0975 seconds
> hbase(main):002:0> get_splits "test"
> Total number of splits = 4
> 10
> 10
> 10
> Took 0.0941 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20151) Bug with SingleColumnValueFilter and FamilyFilter
[
https://issues.apache.org/jira/browse/HBASE-20151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-20151:
--
Attachment: HBASE-20151.master.004.patch
> Bug with SingleColumnValueFilter and FamilyFilter
> -
>
> Key: HBASE-20151
> URL: https://issues.apache.org/jira/browse/HBASE-20151
> Project: HBase
> Issue Type: Bug
> Environment: MacOS 10.13.3
> HBase 1.3.1
>Reporter: Steven Sadowski
>Assignee: Reid Chan
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20151.master.001.patch,
> HBASE-20151.master.002.patch, HBASE-20151.master.003.patch,
> HBASE-20151.master.004.patch, HBASE-20151.master.004.patch
>
>
> When running the following queries, the result is sometimes return correctly
> and other times incorrectly based on the qualifier queried.
> Setup:
> {code:java}
> create 'test', 'a', 'b'
> test = get_table 'test'
> test.put '1', 'a:1', nil
> test.put '1', 'a:10', nil
> test.put '1', 'b:2', nil
> {code}
>
> This query works fine when the SCVF's qualifier has length 1 (i.e. '1') :
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','1',=,'binary:',true,true) AND
> FamilyFilter(=,'binary:b') )"})
> ROW COLUMN+CELL
> 1column=b:2,
> timestamp=1520455888059, value=
> 1 row(s) in 0.0060 seconds
> {code}
>
> The query should return the same result when passed a qualifier of length 2
> (i.e. '10') :
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','10',=,'binary:',true,true) AND
> FamilyFilter(=,'binary:b') )"})
> ROW COLUMN+CELL
> 0 row(s) in 0.0110 seconds
> {code}
> However, in this case, it does not return any row (expected result would be
> to return the same result as the first query).
>
> Removing the family filter while the qualifier is '10' yields expected
> results:
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','10',=,'binary:',true,true) )"})
> ROW COLUMN+CELL
> 1column=a:1,
> timestamp=1520455887954, value=
> 1column=a:10,
> timestamp=1520455888024, value=
> 1column=b:2,
> timestamp=1520455888059, value=
> 1 row(s) in 0.0140 seconds
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20442) clean up incorrect use of commons-collections 3
[
https://issues.apache.org/jira/browse/HBASE-20442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-20442:
Status: Patch Available (was: In Progress)
-v0
- replace commons-collections 3 with hbase-thirdparty version of
commons-collections 4
> clean up incorrect use of commons-collections 3
> ---
>
> Key: HBASE-20442
> URL: https://issues.apache.org/jira/browse/HBASE-20442
> Project: HBase
> Issue Type: Bug
> Components: dependencies, thirdparty
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: HBASE-20442.0.patch
>
>
> we upgraded to commons-collections 4 in HBASE-18704 and then to an
> internal-only hbase-thirdparty version in HBASE-20223, but we've regressed:
> {code}
> $ git grep "import org.apache.commons.collections"
> hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/master/BackupLogCleaner.java:import
> org.apache.commons.collections.MapUtils;
> hbase-client/src/main/java/org/apache/hadoop/hbase/client/RowMutations.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ZKReplicationQueueStorage.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSWALEntry.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java:import
> org.apache.commons.collections.MapUtils;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20442) clean up incorrect use of commons-collections 3
[
https://issues.apache.org/jira/browse/HBASE-20442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-20442:
Attachment: HBASE-20442.0.patch
> clean up incorrect use of commons-collections 3
> ---
>
> Key: HBASE-20442
> URL: https://issues.apache.org/jira/browse/HBASE-20442
> Project: HBase
> Issue Type: Bug
> Components: dependencies, thirdparty
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: HBASE-20442.0.patch
>
>
> we upgraded to commons-collections 4 in HBASE-18704 and then to an
> internal-only hbase-thirdparty version in HBASE-20223, but we've regressed:
> {code}
> $ git grep "import org.apache.commons.collections"
> hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/master/BackupLogCleaner.java:import
> org.apache.commons.collections.MapUtils;
> hbase-client/src/main/java/org/apache/hadoop/hbase/client/RowMutations.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ZKReplicationQueueStorage.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSWALEntry.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java:import
> org.apache.commons.collections.MapUtils;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-18792) hbase-2 needs to defend against hbck operations
[
https://issues.apache.org/jira/browse/HBASE-18792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441547#comment-16441547
]
Umesh Agashe commented on HBASE-18792:
--
Thanks for your review [~busbey].
{quote}VersionInfo is IA.Public, so any public methods become a part of our
supported API. Can we make this method private?
{quote}
Good catch, fixed. Made package private.
{quote}ooof. man that's rough. How about a comment before the if(va ==
VERY_LARGE_NUMBER) that says something like "va and vb must both be the same
and indicate that the version part is a String"?
{quote}
Added comment as you have suggested.
{quote}Also make va, vb, and VERY_LARGE_NUMBER all type Integer instead of int
and use Integer#compareTo(Integer) so that we're not going through a bunch of
autoboxing.
{quote}
We may have to go through autoboxing 2 times on first 2 lines below. If va, vb
and VERY_LARGE_NUMBER are changed to type Integer then we will have to go
through autoboxing in return statement one or two time even if one of the
version components is of type String.
{code:java}
int va = v1Comps[index] instanceof Integer ? (Integer)v1Comps[index] :
VERY_LARGE_NUMBER;
int vb = v2Comps[index] instanceof Integer ? (Integer)v2Comps[index] :
VERY_LARGE_NUMBER;
if (va != vb) {
return va - vb;
}
{code}
{quote}I think this is wrong? like version "2.0.0" should be after
"2.0.0-SNAPSHOT". it's also after "2.0.0-alpha-3" or "2.0.0-beta-1".
Can we expand the versions checked in TestVersionInfo to include a) some "same
major different minor", b) "same minor different maintenance", c) both of the
above, but SNAPSHOT, d) "-alpha" / "-beta"?
{quote}
This comment is on existing comparison logic and needs separate JIRA to track
it. Please see HBASE-20444.
I think the existing version comparison logic is generic and tries to follow
lexicographic comparison. Its not specific to HBase versions. As commented,
2.0.0 should be after 2.0.0-SNAPSHOT and 2.0.0-alpha-3 but it should be before
2.0.0-patch or 2.0.0.1. Similarly 2.0 should be before 2.0.1 As improving
comparison for HBase specific version strings and adding unit tests are not in
scope of hbck changes I have created separate JIRA.
{quote}nit: We should use something like commons-lang's StringUtils#isNumeric
to check this so that we're not relying on exceptions for control flow. on the
other hand, this is a standard Java idiom so no big deal if we keep it.
{quote}
Agree, as these hbck changes doesn't really focus on existing parsing/
comparison logic. This can be addressed with the newly created JIRA HBASE-20444.
Please see the new patch. Thanks!
> hbase-2 needs to defend against hbck operations
> ---
>
> Key: HBASE-18792
> URL: https://issues.apache.org/jira/browse/HBASE-18792
> Project: HBase
> Issue Type: Task
> Components: hbck
>Reporter: stack
>Assignee: Umesh Agashe
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: hbase-18792.master.001.patch,
> hbase-18792.master.002.patch
>
>
> hbck needs updating to run against hbase2. Meantime, if an hbck from hbase1
> is run against hbck2, it may do damage. hbase2 should defend itself against
> hbck1 ops.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-18792) hbase-2 needs to defend against hbck operations
[ https://issues.apache.org/jira/browse/HBASE-18792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Umesh Agashe updated HBASE-18792: - Attachment: hbase-18792.master.002.patch > hbase-2 needs to defend against hbck operations > --- > > Key: HBASE-18792 > URL: https://issues.apache.org/jira/browse/HBASE-18792 > Project: HBase > Issue Type: Task > Components: hbck >Reporter: stack >Assignee: Umesh Agashe >Priority: Blocker > Fix For: 2.0.0 > > Attachments: hbase-18792.master.001.patch, > hbase-18792.master.002.patch > > > hbck needs updating to run against hbase2. Meantime, if an hbck from hbase1 > is run against hbck2, it may do damage. hbase2 should defend itself against > hbck1 ops. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20444) Improve version comparison logic for HBase specific version string and add unit tests
[
https://issues.apache.org/jira/browse/HBASE-20444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Umesh Agashe updated HBASE-20444:
-
Description:
As [~busbey] commented on HBASE-18792, current logic for comparing version
strings in class org.apache.hadoop.hbase.util.VersionInfo is generic and needs
to be improved:
{code:java}
if (index < s1.length) {
// s1 is longer
return 1;
}
{code}
{quote}I think this is wrong? like version "2.0.0" should be after
"2.0.0-SNAPSHOT". it's also after "2.0.0-alpha-3" or "2.0.0-beta-1".
{quote}
Also in other cases 2.0.0 should be before 2.0.0-patch- and 2.0.0.1. Also
2.0 should be before 2.0.1.
{quote}Can we expand the versions checked in TestVersionInfo to include a) some
"same major different minor", b) "same minor different maintenance", c) both of
the above, but SNAPSHOT, d) "-alpha" / "-beta"?
{quote}
was:
As [~busbey] commented on HBASE-18792, current logic for parsing version string
in class org.apache.hadoop.hbase.util.VersionInfo is generic and needs to be
improved:
{code}
if (index < s1.length) {
// s1 is longer
return 1;
}
{code}
bq. I think this is wrong? like version "2.0.0" should be after
"2.0.0-SNAPSHOT". it's also after "2.0.0-alpha-3" or "2.0.0-beta-1".
Also in other cases 2.0.0 should be before 2.0.0-patch- and 2.0.0.1. Also
2.0 should be before 2.0.1.
bq. Can we expand the versions checked in TestVersionInfo to include a) some
"same major different minor", b) "same minor different maintenance", c) both of
the above, but SNAPSHOT, d) "-alpha" / "-beta"?
> Improve version comparison logic for HBase specific version string and add
> unit tests
> -
>
> Key: HBASE-20444
> URL: https://issues.apache.org/jira/browse/HBASE-20444
> Project: HBase
> Issue Type: Improvement
>Reporter: Umesh Agashe
>Priority: Major
>
> As [~busbey] commented on HBASE-18792, current logic for comparing version
> strings in class org.apache.hadoop.hbase.util.VersionInfo is generic and
> needs to be improved:
> {code:java}
> if (index < s1.length) {
> // s1 is longer
> return 1;
> }
> {code}
> {quote}I think this is wrong? like version "2.0.0" should be after
> "2.0.0-SNAPSHOT". it's also after "2.0.0-alpha-3" or "2.0.0-beta-1".
> {quote}
> Also in other cases 2.0.0 should be before 2.0.0-patch- and 2.0.0.1. Also
> 2.0 should be before 2.0.1.
> {quote}Can we expand the versions checked in TestVersionInfo to include a)
> some "same major different minor", b) "same minor different maintenance", c)
> both of the above, but SNAPSHOT, d) "-alpha" / "-beta"?
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20444) Improve version comparison logic for HBase specific version string and add unit tests
[
https://issues.apache.org/jira/browse/HBASE-20444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Umesh Agashe updated HBASE-20444:
-
Summary: Improve version comparison logic for HBase specific version string
and add unit tests (was: Improve parsing logic for HBase specific version
string and add unit tests)
> Improve version comparison logic for HBase specific version string and add
> unit tests
> -
>
> Key: HBASE-20444
> URL: https://issues.apache.org/jira/browse/HBASE-20444
> Project: HBase
> Issue Type: Improvement
>Reporter: Umesh Agashe
>Priority: Major
>
> As [~busbey] commented on HBASE-18792, current logic for parsing version
> string in class org.apache.hadoop.hbase.util.VersionInfo is generic and needs
> to be improved:
> {code}
> if (index < s1.length) {
> // s1 is longer
> return 1;
> }
> {code}
> bq. I think this is wrong? like version "2.0.0" should be after
> "2.0.0-SNAPSHOT". it's also after "2.0.0-alpha-3" or "2.0.0-beta-1".
> Also in other cases 2.0.0 should be before 2.0.0-patch- and 2.0.0.1. Also
> 2.0 should be before 2.0.1.
> bq. Can we expand the versions checked in TestVersionInfo to include a) some
> "same major different minor", b) "same minor different maintenance", c) both
> of the above, but SNAPSHOT, d) "-alpha" / "-beta"?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20445) Defer work when a row lock is busy
[ https://issues.apache.org/jira/browse/HBASE-20445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441535#comment-16441535 ] Andrew Purtell commented on HBASE-20445: I'm not 100% familiar with the state of things in trunk. This is written from a branch-1 perspective, and is for brainstorming and discussion not a complete proposal. Ideally the results can be ported back to a branch-1 minor. Description subject to change as this idea is thought through. > Defer work when a row lock is busy > -- > > Key: HBASE-20445 > URL: https://issues.apache.org/jira/browse/HBASE-20445 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Priority: Major > > Instead of blocking on row locks, defer the call and make the call runner > available so it can service other activity. Have runners pick up deferred > calls in the background after servicing the other request. > Spin briefly on tryLock() wherever we are now using lock() to acquire a row > lock. Introduce two new configuration parameters: one for the amount of time > to wait between lock acquisition attempts, and another for the total number > of times we wait before deferring the work. If the lock cannot be acquired, > put the call back into the call queue. Call queues therefore should be > priority queues sorted by deadline. Currently they are implemented with > LinkedBlockingQueue (which isn't), or AdaptiveLifoCoDelCallQueue (which is) > if the CoDel scheduler is enabled. Perhaps we could just require use of > AdaptiveLifoCoDelCallQueue. Runners will be picking up work from the head of > the queues as long as they are not empty, so deferred calls will be serviced > again, or dropped if the deadline has passed. > Implementing continuations for simple operations should be straightforward. > Batch mutations try to acquire as many rowlocks as they can, then do the > partial batch over the successfully locked rows, then loop back to attempt > the remaining work. This is a partial implementation of what we need so we > can build on it. Rather than loop around, save the partial batch completion > state and put a pointer to it along with the call back into the RPC queue. > For scans where allowPartialResults has been set to true we can simply > complete the call at the point we fail to acquire a row lock. The client will > handle the rest. For scans where allowPartialResults is false we have to save > the scanner state and partial results, and put a pointer to this state along > with the call back into the queue. > We could approach this in phases: > Phase 0 - Sort out the call queuing details. Do we require > AdaptiveLifoCoDelCallQueue? Certainly we can make use of it. Can we also have > RWQueueRpcExecutor create queues as PriorityBlockingQueue instead of > LinkedBlockingQueue? There must be a reason why not already. > Phase 1 - Implement deferral of simple ops only. (Batch mutations and scans > will still block on rowlocks.) > Phase 2 - Implement deferral of batch mutations. (Scans will still block on > rowlocks.) > Phase 3 - Implement deferral of scans where allowPartialResults is false. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20445) Defer work when a row lock is busy
Andrew Purtell created HBASE-20445: -- Summary: Defer work when a row lock is busy Key: HBASE-20445 URL: https://issues.apache.org/jira/browse/HBASE-20445 Project: HBase Issue Type: Improvement Reporter: Andrew Purtell Instead of blocking on row locks, defer the call and make the call runner available so it can service other activity. Have runners pick up deferred calls in the background after servicing the other request. Spin briefly on tryLock() wherever we are now using lock() to acquire a row lock. Introduce two new configuration parameters: one for the amount of time to wait between lock acquisition attempts, and another for the total number of times we wait before deferring the work. If the lock cannot be acquired, put the call back into the call queue. Call queues therefore should be priority queues sorted by deadline. Currently they are implemented with LinkedBlockingQueue (which isn't), or AdaptiveLifoCoDelCallQueue (which is) if the CoDel scheduler is enabled. Perhaps we could just require use of AdaptiveLifoCoDelCallQueue. Runners will be picking up work from the head of the queues as long as they are not empty, so deferred calls will be serviced again, or dropped if the deadline has passed. Implementing continuations for simple operations should be straightforward. Batch mutations try to acquire as many rowlocks as they can, then do the partial batch over the successfully locked rows, then loop back to attempt the remaining work. This is a partial implementation of what we need so we can build on it. Rather than loop around, save the partial batch completion state and put a pointer to it along with the call back into the RPC queue. For scans where allowPartialResults has been set to true we can simply complete the call at the point we fail to acquire a row lock. The client will handle the rest. For scans where allowPartialResults is false we have to save the scanner state and partial results, and put a pointer to this state along with the call back into the queue. We could approach this in phases: Phase 0 - Sort out the call queuing details. Do we require AdaptiveLifoCoDelCallQueue? Certainly we can make use of it. Can we also have RWQueueRpcExecutor create queues as PriorityBlockingQueue instead of LinkedBlockingQueue? There must be a reason why not already. Phase 1 - Implement deferral of simple ops only. (Batch mutations and scans will still block on rowlocks.) Phase 2 - Implement deferral of batch mutations. (Scans will still block on rowlocks.) Phase 3 - Implement deferral of scans where allowPartialResults is false. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20444) Improve parsing logic for HBase specific version string and add unit tests
Umesh Agashe created HBASE-20444:
Summary: Improve parsing logic for HBase specific version string
and add unit tests
Key: HBASE-20444
URL: https://issues.apache.org/jira/browse/HBASE-20444
Project: HBase
Issue Type: Improvement
Reporter: Umesh Agashe
As [~busbey] commented on HBASE-18792, current logic for parsing version string
in class org.apache.hadoop.hbase.util.VersionInfo is generic and needs to be
improved:
{code}
if (index < s1.length) {
// s1 is longer
return 1;
}
{code}
bq. I think this is wrong? like version "2.0.0" should be after
"2.0.0-SNAPSHOT". it's also after "2.0.0-alpha-3" or "2.0.0-beta-1".
Also in other cases 2.0.0 should be before 2.0.0-patch- and 2.0.0.1. Also
2.0 should be before 2.0.1.
bq. Can we expand the versions checked in TestVersionInfo to include a) some
"same major different minor", b) "same minor different maintenance", c) both of
the above, but SNAPSHOT, d) "-alpha" / "-beta"?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20431) Store commit transaction for filesystems that do not support an atomic rename
[ https://issues.apache.org/jira/browse/HBASE-20431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441521#comment-16441521 ] Andrew Purtell commented on HBASE-20431: Description subject to change as this idea is thought through. > Store commit transaction for filesystems that do not support an atomic rename > - > > Key: HBASE-20431 > URL: https://issues.apache.org/jira/browse/HBASE-20431 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell >Priority: Major > > HBase expects the Hadoop filesystem implementation to support an atomic > rename() operation. HDFS does. The S3 backed filesystems do not. The > fundamental issue is the non-atomic and eventually consistent nature of the > S3 service. A S3 bucket is not a filesystem. S3 is not always immediately > read-your-writes. Object metadata can be temporarily inconsistent just after > new objects are stored. There can be a settling period to ride over. > Renaming/moving objects from one path to another are copy operations with > O(file) complexity and O(data) time followed by a series of deletes with > O(file) complexity. Failures at any point prior to completion will leave the > operation in an inconsistent state. The missing atomic rename semantic opens > opportunities for corruption and data loss, which may or may not be > repairable with HBCK. > Handling this at the HBase level could be done with a new multi-step > filesystem transaction framework. Call it StoreCommitTransaction. > SplitTransaction and MergeTransaction are well established cases where even > on HDFS we have non-atomic filesystem changes and are our implementation > template for the new work. In this new StoreCommitTransaction we'd be moving > flush and compaction temporaries out of the temporary directory into the > region store directory. On HDFS the implementation would be easy. We can rely > on the filesystem's atomic rename semantics. On S3 it would be work: First we > would build the list of objects to move, then copy each object into the > destination, and then finally delete all objects at the original path. We > must handle transient errors with retry strategies appropriate for the action > at hand. We must handle serious or permanent errors where the RS doesn't need > to be aborted with a rollback that cleans it all up. Finally, we must handle > permanent errors where the RS must be aborted with a rollback during region > open/recovery. Note that after all objects have been copied and we are > deleting obsolete source objects we must roll forward, not back. To support > recovery after an abort we must utilize the WAL to track transaction > progress. Put markers in for StoreCommitTransaction start and completion > state, with details of the store file(s) involved, so it can be rolled back > during region recovery at open. This will be significant work in HFile, > HStore, flusher, compactor, and HRegion. Wherever we use HDFS's rename now we > would substitute the running of this new multi-step filesystem transaction. > We need to determine this for certain, but I believe on S3 the PUT or > multipart upload of an object must complete before the object is visible, so > we don't have to worry about the case where an object is visible before fully > uploaded as part of normal operations. So an individual object copy will > either happen entirely and the target will then become visible, or it won't > and the target won't exist. > S3 has an optimization, PUT COPY > (https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html), which > the AmazonClient embedded in S3A utilizes for moves. When designing the > StoreCommitTransaction be sure to allow for filesystem implementations that > leverage a server side copy operation. Doing a get-then-put should be > optional. (Not sure Hadoop has an interface that advertises this capability > yet; we can add one if not.) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19924) hbase rpc throttling does not work for multi() with request count rater.
[
https://issues.apache.org/jira/browse/HBASE-19924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441517#comment-16441517
]
huaxiang sun commented on HBASE-19924:
--
Thanks [~stack], I run the failed unittest in my local laptop and it passed.
> hbase rpc throttling does not work for multi() with request count rater.
>
>
> Key: HBASE-19924
> URL: https://issues.apache.org/jira/browse/HBASE-19924
> Project: HBase
> Issue Type: Bug
> Components: rpc
>Affects Versions: 0.16.0, 1.2.6
>Reporter: huaxiang sun
>Assignee: huaxiang sun
>Priority: Major
> Attachments: HBASE-19924-master-v001.patch,
> HBASE-19924-master-v002.patch, HBASE-19924-master-v002.patch,
> HBASE-19924-master-v002.patch
>
>
> Basically, rpc throttling does not work for request count based rater for
> multi. for the following code, when it calls limiter's checkQuota(),
> numWrites/numReads is lost.
> {code:java}
> @Override
> public void checkQuota(int numWrites, int numReads, int numScans) throws
> ThrottlingException {
> writeConsumed = estimateConsume(OperationType.MUTATE, numWrites, 100);
> readConsumed = estimateConsume(OperationType.GET, numReads, 100);
> readConsumed += estimateConsume(OperationType.SCAN, numScans, 1000);
> writeAvailable = Long.MAX_VALUE;
> readAvailable = Long.MAX_VALUE;
> for (final QuotaLimiter limiter : limiters) {
> if (limiter.isBypass()) continue;
> limiter.checkQuota(writeConsumed, readConsumed);
> readAvailable = Math.min(readAvailable, limiter.getReadAvailable());
> writeAvailable = Math.min(writeAvailable, limiter.getWriteAvailable());
> }
> for (final QuotaLimiter limiter : limiters) {
> limiter.grabQuota(writeConsumed, readConsumed);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20443) Add an HBase antipattern check for reintroducing commons-collections 3
Sean Busbey created HBASE-20443:
---
Summary: Add an HBase antipattern check for reintroducing
commons-collections 3
Key: HBASE-20443
URL: https://issues.apache.org/jira/browse/HBASE-20443
Project: HBase
Issue Type: Task
Components: dependencies, test
Reporter: Sean Busbey
we upgraded to commons-collections 4 in HBASE-18704 and then to an
internal-only hbase-thirdparty version in HBASE-20223, but we've regressed:
{code}
$ git grep "import org.apache.commons.collections"
hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/master/BackupLogCleaner.java:import
org.apache.commons.collections.MapUtils;
hbase-client/src/main/java/org/apache/hadoop/hbase/client/RowMutations.java:import
org.apache.commons.collections.CollectionUtils;
hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java:import
org.apache.commons.collections.CollectionUtils;
hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ZKReplicationQueueStorage.java:import
org.apache.commons.collections.CollectionUtils;
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:import
org.apache.commons.collections.CollectionUtils;
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java:import
org.apache.commons.collections.CollectionUtils;
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java:import
org.apache.commons.collections.CollectionUtils;
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSWALEntry.java:import
org.apache.commons.collections.CollectionUtils;
hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java:import
org.apache.commons.collections.CollectionUtils;
hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java:import
org.apache.commons.collections.MapUtils;
{code}
we should add the same kind of check as we do for e.g. hadoop annotations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-20442) clean up incorrect use of commons-collections 3
[
https://issues.apache.org/jira/browse/HBASE-20442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey reassigned HBASE-20442:
---
Assignee: Sean Busbey
> clean up incorrect use of commons-collections 3
> ---
>
> Key: HBASE-20442
> URL: https://issues.apache.org/jira/browse/HBASE-20442
> Project: HBase
> Issue Type: Bug
> Components: dependencies, thirdparty
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 2.0.1
>
>
> we upgraded to commons-collections 4 in HBASE-18704 and then to an
> internal-only hbase-thirdparty version in HBASE-20223, but we've regressed:
> {code}
> $ git grep "import org.apache.commons.collections"
> hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/master/BackupLogCleaner.java:import
> org.apache.commons.collections.MapUtils;
> hbase-client/src/main/java/org/apache/hadoop/hbase/client/RowMutations.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ZKReplicationQueueStorage.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSWALEntry.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java:import
> org.apache.commons.collections.MapUtils;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (HBASE-20442) clean up incorrect use of commons-collections 3
[
https://issues.apache.org/jira/browse/HBASE-20442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HBASE-20442 started by Sean Busbey.
---
> clean up incorrect use of commons-collections 3
> ---
>
> Key: HBASE-20442
> URL: https://issues.apache.org/jira/browse/HBASE-20442
> Project: HBase
> Issue Type: Bug
> Components: dependencies, thirdparty
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 2.0.1
>
>
> we upgraded to commons-collections 4 in HBASE-18704 and then to an
> internal-only hbase-thirdparty version in HBASE-20223, but we've regressed:
> {code}
> $ git grep "import org.apache.commons.collections"
> hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/master/BackupLogCleaner.java:import
> org.apache.commons.collections.MapUtils;
> hbase-client/src/main/java/org/apache/hadoop/hbase/client/RowMutations.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ZKReplicationQueueStorage.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSWALEntry.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java:import
> org.apache.commons.collections.CollectionUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java:import
> org.apache.commons.collections.MapUtils;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20442) clean up incorrect use of commons-collections 3
Sean Busbey created HBASE-20442:
---
Summary: clean up incorrect use of commons-collections 3
Key: HBASE-20442
URL: https://issues.apache.org/jira/browse/HBASE-20442
Project: HBase
Issue Type: Bug
Components: dependencies, thirdparty
Affects Versions: 2.0.0
Reporter: Sean Busbey
Fix For: 2.0.1
we upgraded to commons-collections 4 in HBASE-18704 and then to an
internal-only hbase-thirdparty version in HBASE-20223, but we've regressed:
{code}
$ git grep "import org.apache.commons.collections"
hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/master/BackupLogCleaner.java:import
org.apache.commons.collections.MapUtils;
hbase-client/src/main/java/org/apache/hadoop/hbase/client/RowMutations.java:import
org.apache.commons.collections.CollectionUtils;
hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java:import
org.apache.commons.collections.CollectionUtils;
hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ZKReplicationQueueStorage.java:import
org.apache.commons.collections.CollectionUtils;
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:import
org.apache.commons.collections.CollectionUtils;
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java:import
org.apache.commons.collections.CollectionUtils;
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java:import
org.apache.commons.collections.CollectionUtils;
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSWALEntry.java:import
org.apache.commons.collections.CollectionUtils;
hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java:import
org.apache.commons.collections.CollectionUtils;
hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java:import
org.apache.commons.collections.MapUtils;
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20440) Clean up incorrect use of commons-lang 2.y
[
https://issues.apache.org/jira/browse/HBASE-20440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-20440:
Status: Patch Available (was: In Progress)
-v0
- clean up use of commons-lang 2
> Clean up incorrect use of commons-lang 2.y
> --
>
> Key: HBASE-20440
> URL: https://issues.apache.org/jira/browse/HBASE-20440
> Project: HBase
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: HBASE-20440.0.patch
>
>
> We updated to commons-lang 3 in HBASE-18674 but we've regressed:
> {code}
> $ git grep org.apache.commons.lang\\.
> hbase-common/src/main/java/org/apache/hadoop/hbase/net/Address.java:import
> org.apache.commons.lang.StringUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierFactoryImpl.java:import
> org.apache.commons.lang.builder.HashCodeBuilder;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierImpl.java:import
> org.apache.commons.lang.builder.HashCodeBuilder;
> hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHdfsSnapshotHRegion.java:import
> org.apache.commons.lang.StringUtils;
> hbase-server/src/test/java/org/apache/hadoop/hbase/util/compaction/TestMajorCompactionRequest.java:import
> org.apache.commons.lang.RandomStringUtils;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20440) Clean up incorrect use of commons-lang 2.y
[
https://issues.apache.org/jira/browse/HBASE-20440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-20440:
Attachment: HBASE-20440.0.patch
> Clean up incorrect use of commons-lang 2.y
> --
>
> Key: HBASE-20440
> URL: https://issues.apache.org/jira/browse/HBASE-20440
> Project: HBase
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: HBASE-20440.0.patch
>
>
> We updated to commons-lang 3 in HBASE-18674 but we've regressed:
> {code}
> $ git grep org.apache.commons.lang\\.
> hbase-common/src/main/java/org/apache/hadoop/hbase/net/Address.java:import
> org.apache.commons.lang.StringUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierFactoryImpl.java:import
> org.apache.commons.lang.builder.HashCodeBuilder;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierImpl.java:import
> org.apache.commons.lang.builder.HashCodeBuilder;
> hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHdfsSnapshotHRegion.java:import
> org.apache.commons.lang.StringUtils;
> hbase-server/src/test/java/org/apache/hadoop/hbase/util/compaction/TestMajorCompactionRequest.java:import
> org.apache.commons.lang.RandomStringUtils;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19924) hbase rpc throttling does not work for multi() with request count rater.
[
https://issues.apache.org/jira/browse/HBASE-19924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441487#comment-16441487
]
stack commented on HBASE-19924:
---
Retry [~huaxiang] I think that test is flakey though it doesn't show in our
flakies dashboard. Patch looks good. Let me retry.
> hbase rpc throttling does not work for multi() with request count rater.
>
>
> Key: HBASE-19924
> URL: https://issues.apache.org/jira/browse/HBASE-19924
> Project: HBase
> Issue Type: Bug
> Components: rpc
>Affects Versions: 0.16.0, 1.2.6
>Reporter: huaxiang sun
>Assignee: huaxiang sun
>Priority: Major
> Attachments: HBASE-19924-master-v001.patch,
> HBASE-19924-master-v002.patch, HBASE-19924-master-v002.patch,
> HBASE-19924-master-v002.patch
>
>
> Basically, rpc throttling does not work for request count based rater for
> multi. for the following code, when it calls limiter's checkQuota(),
> numWrites/numReads is lost.
> {code:java}
> @Override
> public void checkQuota(int numWrites, int numReads, int numScans) throws
> ThrottlingException {
> writeConsumed = estimateConsume(OperationType.MUTATE, numWrites, 100);
> readConsumed = estimateConsume(OperationType.GET, numReads, 100);
> readConsumed += estimateConsume(OperationType.SCAN, numScans, 1000);
> writeAvailable = Long.MAX_VALUE;
> readAvailable = Long.MAX_VALUE;
> for (final QuotaLimiter limiter : limiters) {
> if (limiter.isBypass()) continue;
> limiter.checkQuota(writeConsumed, readConsumed);
> readAvailable = Math.min(readAvailable, limiter.getReadAvailable());
> writeAvailable = Math.min(writeAvailable, limiter.getWriteAvailable());
> }
> for (final QuotaLimiter limiter : limiters) {
> limiter.grabQuota(writeConsumed, readConsumed);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-19924) hbase rpc throttling does not work for multi() with request count rater.
[
https://issues.apache.org/jira/browse/HBASE-19924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-19924:
--
Attachment: HBASE-19924-master-v002.patch
> hbase rpc throttling does not work for multi() with request count rater.
>
>
> Key: HBASE-19924
> URL: https://issues.apache.org/jira/browse/HBASE-19924
> Project: HBase
> Issue Type: Bug
> Components: rpc
>Affects Versions: 0.16.0, 1.2.6
>Reporter: huaxiang sun
>Assignee: huaxiang sun
>Priority: Major
> Attachments: HBASE-19924-master-v001.patch,
> HBASE-19924-master-v002.patch, HBASE-19924-master-v002.patch,
> HBASE-19924-master-v002.patch
>
>
> Basically, rpc throttling does not work for request count based rater for
> multi. for the following code, when it calls limiter's checkQuota(),
> numWrites/numReads is lost.
> {code:java}
> @Override
> public void checkQuota(int numWrites, int numReads, int numScans) throws
> ThrottlingException {
> writeConsumed = estimateConsume(OperationType.MUTATE, numWrites, 100);
> readConsumed = estimateConsume(OperationType.GET, numReads, 100);
> readConsumed += estimateConsume(OperationType.SCAN, numScans, 1000);
> writeAvailable = Long.MAX_VALUE;
> readAvailable = Long.MAX_VALUE;
> for (final QuotaLimiter limiter : limiters) {
> if (limiter.isBypass()) continue;
> limiter.checkQuota(writeConsumed, readConsumed);
> readAvailable = Math.min(readAvailable, limiter.getReadAvailable());
> writeAvailable = Math.min(writeAvailable, limiter.getWriteAvailable());
> }
> for (final QuotaLimiter limiter : limiters) {
> limiter.grabQuota(writeConsumed, readConsumed);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19924) hbase rpc throttling does not work for multi() with request count rater.
[
https://issues.apache.org/jira/browse/HBASE-19924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441475#comment-16441475
]
Hadoop QA commented on HBASE-19924:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
49s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
58s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 6s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}110m 27s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}156m 50s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.TestJMXListener |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-19924 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12919461/HBASE-19924-master-v002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 2d1747ec6c78 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 357a089e06 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/12501/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12501/testReport/ |
| Max. process+thread count | 4294 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
[jira] [Created] (HBASE-20441) Add an HBase antipattern check for reintroducing commons-lang 2
Sean Busbey created HBASE-20441:
---
Summary: Add an HBase antipattern check for reintroducing
commons-lang 2
Key: HBASE-20441
URL: https://issues.apache.org/jira/browse/HBASE-20441
Project: HBase
Issue Type: Task
Components: dependencies, test
Affects Versions: 2.0.0
Reporter: Sean Busbey
Fix For: 2.0.1
We updated to commons-lang 3 in HBASE-18674 but we've regressed:
{code}
$ git grep org.apache.commons.lang\\.
hbase-common/src/main/java/org/apache/hadoop/hbase/net/Address.java:import
org.apache.commons.lang.StringUtils;
hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierFactoryImpl.java:import
org.apache.commons.lang.builder.HashCodeBuilder;
hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierImpl.java:import
org.apache.commons.lang.builder.HashCodeBuilder;
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHdfsSnapshotHRegion.java:import
org.apache.commons.lang.StringUtils;
hbase-server/src/test/java/org/apache/hadoop/hbase/util/compaction/TestMajorCompactionRequest.java:import
org.apache.commons.lang.RandomStringUtils;
{code}
we should add the same kind of check as we do for e.g. hadoop annotations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-20440) Clean up incorrect use of commons-lang 2.y
[
https://issues.apache.org/jira/browse/HBASE-20440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey reassigned HBASE-20440:
---
Assignee: Sean Busbey
> Clean up incorrect use of commons-lang 2.y
> --
>
> Key: HBASE-20440
> URL: https://issues.apache.org/jira/browse/HBASE-20440
> Project: HBase
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 2.0.1
>
>
> We updated to commons-lang 3 in HBASE-18674 but we've regressed:
> {code}
> $ git grep org.apache.commons.lang\\.
> hbase-common/src/main/java/org/apache/hadoop/hbase/net/Address.java:import
> org.apache.commons.lang.StringUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierFactoryImpl.java:import
> org.apache.commons.lang.builder.HashCodeBuilder;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierImpl.java:import
> org.apache.commons.lang.builder.HashCodeBuilder;
> hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHdfsSnapshotHRegion.java:import
> org.apache.commons.lang.StringUtils;
> hbase-server/src/test/java/org/apache/hadoop/hbase/util/compaction/TestMajorCompactionRequest.java:import
> org.apache.commons.lang.RandomStringUtils;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (HBASE-20440) Clean up incorrect use of commons-lang 2.y
[
https://issues.apache.org/jira/browse/HBASE-20440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HBASE-20440 started by Sean Busbey.
---
> Clean up incorrect use of commons-lang 2.y
> --
>
> Key: HBASE-20440
> URL: https://issues.apache.org/jira/browse/HBASE-20440
> Project: HBase
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 2.0.1
>
>
> We updated to commons-lang 3 in HBASE-18674 but we've regressed:
> {code}
> $ git grep org.apache.commons.lang\\.
> hbase-common/src/main/java/org/apache/hadoop/hbase/net/Address.java:import
> org.apache.commons.lang.StringUtils;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierFactoryImpl.java:import
> org.apache.commons.lang.builder.HashCodeBuilder;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierImpl.java:import
> org.apache.commons.lang.builder.HashCodeBuilder;
> hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHdfsSnapshotHRegion.java:import
> org.apache.commons.lang.StringUtils;
> hbase-server/src/test/java/org/apache/hadoop/hbase/util/compaction/TestMajorCompactionRequest.java:import
> org.apache.commons.lang.RandomStringUtils;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20440) Clean up incorrect use of commons-lang 2.y
Sean Busbey created HBASE-20440:
---
Summary: Clean up incorrect use of commons-lang 2.y
Key: HBASE-20440
URL: https://issues.apache.org/jira/browse/HBASE-20440
Project: HBase
Issue Type: Bug
Components: dependencies
Affects Versions: 2.0.0
Reporter: Sean Busbey
Fix For: 2.0.1
We updated to commons-lang 3 in HBASE-18674 but we've regressed:
{code}
$ git grep org.apache.commons.lang\\.
hbase-common/src/main/java/org/apache/hadoop/hbase/net/Address.java:import
org.apache.commons.lang.StringUtils;
hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierFactoryImpl.java:import
org.apache.commons.lang.builder.HashCodeBuilder;
hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierImpl.java:import
org.apache.commons.lang.builder.HashCodeBuilder;
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHdfsSnapshotHRegion.java:import
org.apache.commons.lang.StringUtils;
hbase-server/src/test/java/org/apache/hadoop/hbase/util/compaction/TestMajorCompactionRequest.java:import
org.apache.commons.lang.RandomStringUtils;
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20439) Clean up incorrect use of commons-logging in hbase-server
[
https://issues.apache.org/jira/browse/HBASE-20439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-20439:
Status: Patch Available (was: In Progress)
> Clean up incorrect use of commons-logging in hbase-server
> -
>
> Key: HBASE-20439
> URL: https://issues.apache.org/jira/browse/HBASE-20439
> Project: HBase
> Issue Type: Bug
> Components: dependencies, logging
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Fix For: 2.0.1
>
> Attachments: HBASE-20439.0.patch
>
>
> We moved to slf4j in HBASE-10092, but looking at our source tree we've had
> some regression back to commons-logging:
> {code}
> $ git grep -E "org.apache.commons.logging.Log(Factory|;)"
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/zksyncer/ClientZKSyncer.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/zksyncer/ClientZKSyncer.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierImpl.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/FileArchiverNotifierImpl.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/RegionSizeReportingChore.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/RegionSizeReportingChore.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/RegionSizeStoreImpl.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/RegionSizeStoreImpl.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/throttle/StoreHotnessProtector.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/throttle/StoreHotnessProtector.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/TestClusterPortAssignment.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/TestClusterPortAssignment.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFlushFromClient.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFlushFromClient.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestSeparateClientZKCluster.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestSeparateClientZKCluster.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/procedure/TestFailedProcCleanup.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/procedure/TestFailedProcCleanup.java:import
> org.apache.commons.logging.LogFactory;
> hbase-server/src/test/java/org/apache/hadoop/hbase/wal/TestDisabledWAL.java:import
> org.apache.commons.logging.Log;
> hbase-server/src/test/java/org/apache/hadoop/hbase/wal/TestDisabledWAL.java:import
> org.apache.commons.logging.LogFactory;
> {code}
> replace with slf4j
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
