[jira] [Commented] (HBASE-17356) Add replica get support
[
https://issues.apache.org/jira/browse/HBASE-17356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732739#comment-16732739
]
Hudson commented on HBASE-17356:
Results for branch branch-2.1
[build #738 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/738/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/738//console].
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/738//console].
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/738//console].
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Add replica get support
> ---
>
> Key: HBASE-17356
> URL: https://issues.apache.org/jira/browse/HBASE-17356
> Project: HBase
> Issue Type: Sub-task
> Components: Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-17356-v1.patch, HBASE-17356-v2.patch,
> HBASE-17356-v2.patch, HBASE-17356-v3.patch, HBASE-17356-v4.patch,
> HBASE-17356-v5.patch, HBASE-17356-v5.patch, HBASE-17356.patch
>
>
> I think we can do better for scan at least as now we will pass the mvcc to
> client. We can use the mvcc to determine if we can get a consistent view when
> reading from replicas other than primary.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21662) Add append_peer_exclude_namespaces and remove_peer_exclude_namespaces shell commands
[
https://issues.apache.org/jira/browse/HBASE-21662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732742#comment-16732742
]
Hudson commented on HBASE-21662:
Results for branch branch-2
[build #1590 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1590/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1590//console].
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1590//console].
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1590//console].
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Add append_peer_exclude_namespaces and remove_peer_exclude_namespaces shell
> commands
>
>
> Key: HBASE-21662
> URL: https://issues.apache.org/jira/browse/HBASE-21662
> Project: HBase
> Issue Type: Improvement
>Reporter: Yi Mei
>Assignee: Yi Mei
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21662.master.001.patch,
> HBASE-21662.master.002.patch
>
>
> To add or remove a namespace to peers' exclude namespace list, the current
> way is use set_peer_exclude_namespaces. But one have to copy all exclude
> namespaces of the peer firstly and modify it, which is error-prone and
> time-consuming.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21662) Add append_peer_exclude_namespaces and remove_peer_exclude_namespaces shell commands
[
https://issues.apache.org/jira/browse/HBASE-21662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732740#comment-16732740
]
Hudson commented on HBASE-21662:
Results for branch branch-2.1
[build #738 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/738/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/738//console].
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/738//console].
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/738//console].
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Add append_peer_exclude_namespaces and remove_peer_exclude_namespaces shell
> commands
>
>
> Key: HBASE-21662
> URL: https://issues.apache.org/jira/browse/HBASE-21662
> Project: HBase
> Issue Type: Improvement
>Reporter: Yi Mei
>Assignee: Yi Mei
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21662.master.001.patch,
> HBASE-21662.master.002.patch
>
>
> To add or remove a namespace to peers' exclude namespace list, the current
> way is use set_peer_exclude_namespaces. But one have to copy all exclude
> namespaces of the peer firstly and modify it, which is error-prone and
> time-consuming.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-17356) Add replica get support
[
https://issues.apache.org/jira/browse/HBASE-17356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732741#comment-16732741
]
Hudson commented on HBASE-17356:
Results for branch branch-2
[build #1590 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1590/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1590//console].
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1590//console].
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1590//console].
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Add replica get support
> ---
>
> Key: HBASE-17356
> URL: https://issues.apache.org/jira/browse/HBASE-17356
> Project: HBase
> Issue Type: Sub-task
> Components: Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-17356-v1.patch, HBASE-17356-v2.patch,
> HBASE-17356-v2.patch, HBASE-17356-v3.patch, HBASE-17356-v4.patch,
> HBASE-17356-v5.patch, HBASE-17356-v5.patch, HBASE-17356.patch
>
>
> I think we can do better for scan at least as now we will pass the mvcc to
> client. We can use the mvcc to determine if we can get a consistent view when
> reading from replicas other than primary.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-17356) Add replica get support
[
https://issues.apache.org/jira/browse/HBASE-17356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732751#comment-16732751
]
Hudson commented on HBASE-17356:
Results for branch master
[build #694 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/694/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/master/694//console].
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/master/694//console].
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/master/694//console].
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Add replica get support
> ---
>
> Key: HBASE-17356
> URL: https://issues.apache.org/jira/browse/HBASE-17356
> Project: HBase
> Issue Type: Sub-task
> Components: Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-17356-v1.patch, HBASE-17356-v2.patch,
> HBASE-17356-v2.patch, HBASE-17356-v3.patch, HBASE-17356-v4.patch,
> HBASE-17356-v5.patch, HBASE-17356-v5.patch, HBASE-17356.patch
>
>
> I think we can do better for scan at least as now we will pass the mvcc to
> client. We can use the mvcc to determine if we can get a consistent view when
> reading from replicas other than primary.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21662) Add append_peer_exclude_namespaces and remove_peer_exclude_namespaces shell commands
[
https://issues.apache.org/jira/browse/HBASE-21662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732752#comment-16732752
]
Hudson commented on HBASE-21662:
Results for branch master
[build #694 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/694/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/master/694//console].
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/master/694//console].
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/master/694//console].
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Add append_peer_exclude_namespaces and remove_peer_exclude_namespaces shell
> commands
>
>
> Key: HBASE-21662
> URL: https://issues.apache.org/jira/browse/HBASE-21662
> Project: HBase
> Issue Type: Improvement
>Reporter: Yi Mei
>Assignee: Yi Mei
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21662.master.001.patch,
> HBASE-21662.master.002.patch
>
>
> To add or remove a namespace to peers' exclude namespace list, the current
> way is use set_peer_exclude_namespaces. But one have to copy all exclude
> namespaces of the peer firstly and modify it, which is error-prone and
> time-consuming.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21159) Add shell command to switch throttle on or off
[
https://issues.apache.org/jira/browse/HBASE-21159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732767#comment-16732767
]
Hadoop QA commented on HBASE-21159:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 3m
42s{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 4 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
23s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
5s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
9s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
11s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
7s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
12s{color} | {color:red} The patch generated 6 new + 149 unchanged - 2 fixed =
155 total (was 151) {color} |
| {color:orange}-0{color} | {color:orange} ruby-lint {color} | {color:orange}
0m 7s{color} | {color:orange} The patch generated 14 new + 270 unchanged - 0
fixed = 284 total (was 270) {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
7s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 32s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
1m 54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
11s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
32s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
14s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}246m 47s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 11m
1s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
37s{color} | {color:green} The patch does not generate ASF License
[jira] [Created] (HBASE-21667) Move to latest ASF Parent POM
Peter Somogyi created HBASE-21667: - Summary: Move to latest ASF Parent POM Key: HBASE-21667 URL: https://issues.apache.org/jira/browse/HBASE-21667 Project: HBase Issue Type: Improvement Reporter: Peter Somogyi Assignee: Peter Somogyi Fix For: 3.0.0, 2.2.0 Currently HBase depends on version 18 which was released on 2016-05-18. Version 21 was released in August 2018. Relevant dependency upgrades ||Name||Currently used version||New version||Notes|| |surefire.version|2.21.0|2.22.0| | |maven-compiler-plugin|3.6.1|3.7| | |maven-dependency-plugin|3.0.1|3.1.1| | |maven-jar-plugin|3.0.0|3.0.2| | |maven-javadoc-plugin|3.0.0|3.0.1| | |maven-resources-plugin|2.7|3.1.0| | |maven-site-plugin|3.4|3.7.1|Currently not relying on ASF version. See: HBASE-18333| |maven-source-plugin|3.0.0|3.0.1| | |maven-shade-plugin|3.0.0|3.1.1|Newly added to ASF pom| |maven-clean-plugin|3.0.0|3.1.0| | |maven-project-info-reports-plugin |2.9|3.0.0| | Version 21 added net.nicoulaj.maven.plugins:checksum-maven-plugin which introduced SHA512 checksum instead of SHA1. Should verify if we can rely on that for releases or breaks our current processes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21588) Procedure v2 wal splitting implementation
[
https://issues.apache.org/jira/browse/HBASE-21588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732819#comment-16732819
]
Hadoop QA commented on HBASE-21588:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
15s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color: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 7 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
26s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
10s{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
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
56s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s{color} | {color:green} The patch passed checkstyle in hbase-protocol-shaded
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s{color} | {color:green} The patch passed checkstyle in hbase-common {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
8s{color} | {color:green} hbase-server: The patch generated 0 new + 271
unchanged - 1 fixed = 271 total (was 272) {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
11s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 32s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
1m 31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
56s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
33s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
45s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}140m 27s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
50s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}195m 41s{color} |
{color:black} {c
[jira] [Updated] (HBASE-21588) Procedure v2 wal splitting implementation
[ https://issues.apache.org/jira/browse/HBASE-21588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-21588: - Attachment: HBASE-21588.master.019.patch > Procedure v2 wal splitting implementation > - > > Key: HBASE-21588 > URL: https://issues.apache.org/jira/browse/HBASE-21588 > Project: HBase > Issue Type: Sub-task >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Attachments: HBASE-21588.master.003.patch, > HBASE-21588.master.004.patch, HBASE-21588.master.005.patch, > HBASE-21588.master.006.patch, HBASE-21588.master.007.patch, > HBASE-21588.master.008.patch, HBASE-21588.master.009.patch, > HBASE-21588.master.010.patch, HBASE-21588.master.011.patch, > HBASE-21588.master.012.patch, HBASE-21588.master.013.patch, > HBASE-21588.master.014.patch, HBASE-21588.master.015.patch, > HBASE-21588.master.016.patch, HBASE-21588.master.017.patch, > HBASE-21588.master.018.patch, HBASE-21588.master.018.patch, > HBASE-21588.master.019.patch > > > create a sub task to submit the implementation of procedure v2 wal splitting -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21588) Procedure v2 wal splitting implementation
[ https://issues.apache.org/jira/browse/HBASE-21588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732853#comment-16732853 ] Jingyun Tian commented on HBASE-21588: -- Failed UT is stuck at TearDown. Try to kill the HBase cluster before shutdown it. > Procedure v2 wal splitting implementation > - > > Key: HBASE-21588 > URL: https://issues.apache.org/jira/browse/HBASE-21588 > Project: HBase > Issue Type: Sub-task >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Attachments: HBASE-21588.master.003.patch, > HBASE-21588.master.004.patch, HBASE-21588.master.005.patch, > HBASE-21588.master.006.patch, HBASE-21588.master.007.patch, > HBASE-21588.master.008.patch, HBASE-21588.master.009.patch, > HBASE-21588.master.010.patch, HBASE-21588.master.011.patch, > HBASE-21588.master.012.patch, HBASE-21588.master.013.patch, > HBASE-21588.master.014.patch, HBASE-21588.master.015.patch, > HBASE-21588.master.016.patch, HBASE-21588.master.017.patch, > HBASE-21588.master.018.patch, HBASE-21588.master.018.patch, > HBASE-21588.master.019.patch > > > create a sub task to submit the implementation of procedure v2 wal splitting -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21588) Procedure v2 wal splitting implementation
[ https://issues.apache.org/jira/browse/HBASE-21588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732871#comment-16732871 ] Guanghao Zhang commented on HBASE-21588: The ut passed locally and only failed in HADOOP QA? > Procedure v2 wal splitting implementation > - > > Key: HBASE-21588 > URL: https://issues.apache.org/jira/browse/HBASE-21588 > Project: HBase > Issue Type: Sub-task >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Attachments: HBASE-21588.master.003.patch, > HBASE-21588.master.004.patch, HBASE-21588.master.005.patch, > HBASE-21588.master.006.patch, HBASE-21588.master.007.patch, > HBASE-21588.master.008.patch, HBASE-21588.master.009.patch, > HBASE-21588.master.010.patch, HBASE-21588.master.011.patch, > HBASE-21588.master.012.patch, HBASE-21588.master.013.patch, > HBASE-21588.master.014.patch, HBASE-21588.master.015.patch, > HBASE-21588.master.016.patch, HBASE-21588.master.017.patch, > HBASE-21588.master.018.patch, HBASE-21588.master.018.patch, > HBASE-21588.master.019.patch > > > create a sub task to submit the implementation of procedure v2 wal splitting -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21667) Move to latest ASF Parent POM
[ https://issues.apache.org/jira/browse/HBASE-21667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732876#comment-16732876 ] Duo Zhang commented on HBASE-21667: --- Do we really need to depend on this parent pom? > Move to latest ASF Parent POM > - > > Key: HBASE-21667 > URL: https://issues.apache.org/jira/browse/HBASE-21667 > Project: HBase > Issue Type: Improvement >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Minor > Fix For: 3.0.0, 2.2.0 > > > Currently HBase depends on version 18 which was released on 2016-05-18. > Version 21 was released in August 2018. > Relevant dependency upgrades > > ||Name||Currently used version||New version||Notes|| > |surefire.version|2.21.0|2.22.0| | > |maven-compiler-plugin|3.6.1|3.7| | > |maven-dependency-plugin|3.0.1|3.1.1| | > |maven-jar-plugin|3.0.0|3.0.2| | > |maven-javadoc-plugin|3.0.0|3.0.1| | > |maven-resources-plugin|2.7|3.1.0| | > |maven-site-plugin|3.4|3.7.1|Currently not relying on ASF version. See: > HBASE-18333| > |maven-source-plugin|3.0.0|3.0.1| | > |maven-shade-plugin|3.0.0|3.1.1|Newly added to ASF pom| > |maven-clean-plugin|3.0.0|3.1.0| | > |maven-project-info-reports-plugin |2.9|3.0.0| | > Version 21 added net.nicoulaj.maven.plugins:checksum-maven-plugin which > introduced SHA512 checksum instead of SHA1. Should verify if we can rely on > that for releases or breaks our current processes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21159) Add shell command to switch throttle on or off
[ https://issues.apache.org/jira/browse/HBASE-21159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Mei updated HBASE-21159: --- Attachment: HBASE-21159.master.007.patch > Add shell command to switch throttle on or off > -- > > Key: HBASE-21159 > URL: https://issues.apache.org/jira/browse/HBASE-21159 > Project: HBase > Issue Type: Sub-task >Affects Versions: 3.0.0, 2.2.0 >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > Attachments: HBASE-21159.master.001.patch, > HBASE-21159.master.002.patch, HBASE-21159.master.003.patch, > HBASE-21159.master.004.patch, HBASE-21159.master.005.patch, > HBASE-21159.master.006.patch, HBASE-21159.master.007.patch > > > Add shell command to switch throttle on or off. When throttle is off, HBase > will not throttle any request. This feature may be useful in production > environment. > We can use the following commands to switch throttle: > throttle_switch true / throttle_switch false -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21573) More sensible client default timeout values
[ https://issues.apache.org/jira/browse/HBASE-21573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-21573: -- Attachment: HBASE-21573.master.001.patch > More sensible client default timeout values > --- > > Key: HBASE-21573 > URL: https://issues.apache.org/jira/browse/HBASE-21573 > Project: HBase > Issue Type: Wish > Components: Client >Affects Versions: 2.1.1 >Reporter: Cosmin Lehene >Priority: Critical > Fix For: 2.1.3 > > Attachments: HBASE-21573.master.001.patch > > > I guess the goal is to have operations allow enough time to recover from > major failures. > While this may make sense for large jobs, it's a PITA for OLTP scenarios and > could probably benefit from a faster failure mode in default > > hbase.rpc.timeout = 6 > hbase.client.operation.timeout = 120 > hbase.client.meta.operation.timeout = 120 > The client meta ops timeout is not in defaults-xml and not documented in the > book either. > [https://hbase.apache.org/book.html#config_timeouts] > > Would it make sense to have aggressive defaults instead? > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21573) More sensible client default timeout values
[ https://issues.apache.org/jira/browse/HBASE-21573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-21573: -- Assignee: Peter Somogyi Status: Patch Available (was: Open) > More sensible client default timeout values > --- > > Key: HBASE-21573 > URL: https://issues.apache.org/jira/browse/HBASE-21573 > Project: HBase > Issue Type: Wish > Components: Client >Affects Versions: 2.1.1 >Reporter: Cosmin Lehene >Assignee: Peter Somogyi >Priority: Critical > Fix For: 2.1.3 > > Attachments: HBASE-21573.master.001.patch > > > I guess the goal is to have operations allow enough time to recover from > major failures. > While this may make sense for large jobs, it's a PITA for OLTP scenarios and > could probably benefit from a faster failure mode in default > > hbase.rpc.timeout = 6 > hbase.client.operation.timeout = 120 > hbase.client.meta.operation.timeout = 120 > The client meta ops timeout is not in defaults-xml and not documented in the > book either. > [https://hbase.apache.org/book.html#config_timeouts] > > Would it make sense to have aggressive defaults instead? > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21662) Add append_peer_exclude_namespaces and remove_peer_exclude_namespaces shell commands
[
https://issues.apache.org/jira/browse/HBASE-21662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732900#comment-16732900
]
Hudson commented on HBASE-21662:
Results for branch branch-2.0
[build #1223 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1223/]:
(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/1223//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1223//console].
(/) {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/1223//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Add append_peer_exclude_namespaces and remove_peer_exclude_namespaces shell
> commands
>
>
> Key: HBASE-21662
> URL: https://issues.apache.org/jira/browse/HBASE-21662
> Project: HBase
> Issue Type: Improvement
>Reporter: Yi Mei
>Assignee: Yi Mei
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21662.master.001.patch,
> HBASE-21662.master.002.patch
>
>
> To add or remove a namespace to peers' exclude namespace list, the current
> way is use set_peer_exclude_namespaces. But one have to copy all exclude
> namespaces of the peer firstly and modify it, which is error-prone and
> time-consuming.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-18569) Add prefetch support for async region locator
[
https://issues.apache.org/jira/browse/HBASE-18569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732901#comment-16732901
]
Hudson commented on HBASE-18569:
Results for branch branch-2.0
[build #1223 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1223/]:
(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/1223//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1223//console].
(/) {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/1223//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Add prefetch support for async region locator
> -
>
> Key: HBASE-18569
> URL: https://issues.apache.org/jira/browse/HBASE-18569
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 2.0.5
>
> Attachments: HBASE-18569-v1.patch, HBASE-18569.patch
>
>
> It will be useful for large tables.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-17356) Add replica get support
[
https://issues.apache.org/jira/browse/HBASE-17356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732902#comment-16732902
]
Hudson commented on HBASE-17356:
Results for branch branch-2.0
[build #1223 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1223/]:
(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/1223//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1223//console].
(/) {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/1223//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Add replica get support
> ---
>
> Key: HBASE-17356
> URL: https://issues.apache.org/jira/browse/HBASE-17356
> Project: HBase
> Issue Type: Sub-task
> Components: Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-17356-v1.patch, HBASE-17356-v2.patch,
> HBASE-17356-v2.patch, HBASE-17356-v3.patch, HBASE-17356-v4.patch,
> HBASE-17356-v5.patch, HBASE-17356-v5.patch, HBASE-17356.patch
>
>
> I think we can do better for scan at least as now we will pass the mvcc to
> client. We can use the mvcc to determine if we can get a consistent view when
> reading from replicas other than primary.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21667) Move to latest ASF Parent POM
[
https://issues.apache.org/jira/browse/HBASE-21667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732899#comment-16732899
]
Peter Somogyi commented on HBASE-21667:
---
{quote}Do we really need to depend on this parent pom?
{quote}
Do you mean to remove the 'parent' element from our main pom or just not
upgrading from v18 to v21?
> Move to latest ASF Parent POM
> -
>
> Key: HBASE-21667
> URL: https://issues.apache.org/jira/browse/HBASE-21667
> Project: HBase
> Issue Type: Improvement
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Minor
> Fix For: 3.0.0, 2.2.0
>
>
> Currently HBase depends on version 18 which was released on 2016-05-18.
> Version 21 was released in August 2018.
> Relevant dependency upgrades
>
> ||Name||Currently used version||New version||Notes||
> |surefire.version|2.21.0|2.22.0| |
> |maven-compiler-plugin|3.6.1|3.7| |
> |maven-dependency-plugin|3.0.1|3.1.1| |
> |maven-jar-plugin|3.0.0|3.0.2| |
> |maven-javadoc-plugin|3.0.0|3.0.1| |
> |maven-resources-plugin|2.7|3.1.0| |
> |maven-site-plugin|3.4|3.7.1|Currently not relying on ASF version. See:
> HBASE-18333|
> |maven-source-plugin|3.0.0|3.0.1| |
> |maven-shade-plugin|3.0.0|3.1.1|Newly added to ASF pom|
> |maven-clean-plugin|3.0.0|3.1.0| |
> |maven-project-info-reports-plugin |2.9|3.0.0| |
> Version 21 added net.nicoulaj.maven.plugins:checksum-maven-plugin which
> introduced SHA512 checksum instead of SHA1. Should verify if we can rely on
> that for releases or breaks our current processes.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21667) Move to latest ASF Parent POM
[ https://issues.apache.org/jira/browse/HBASE-21667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732907#comment-16732907 ] Duo Zhang commented on HBASE-21667: --- I mean just remove it and manage the dependencies by our own. Is there any asf policies that require us to depend on the parent pom? Or any advantages? > Move to latest ASF Parent POM > - > > Key: HBASE-21667 > URL: https://issues.apache.org/jira/browse/HBASE-21667 > Project: HBase > Issue Type: Improvement >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Minor > Fix For: 3.0.0, 2.2.0 > > > Currently HBase depends on version 18 which was released on 2016-05-18. > Version 21 was released in August 2018. > Relevant dependency upgrades > > ||Name||Currently used version||New version||Notes|| > |surefire.version|2.21.0|2.22.0| | > |maven-compiler-plugin|3.6.1|3.7| | > |maven-dependency-plugin|3.0.1|3.1.1| | > |maven-jar-plugin|3.0.0|3.0.2| | > |maven-javadoc-plugin|3.0.0|3.0.1| | > |maven-resources-plugin|2.7|3.1.0| | > |maven-site-plugin|3.4|3.7.1|Currently not relying on ASF version. See: > HBASE-18333| > |maven-source-plugin|3.0.0|3.0.1| | > |maven-shade-plugin|3.0.0|3.1.1|Newly added to ASF pom| > |maven-clean-plugin|3.0.0|3.1.0| | > |maven-project-info-reports-plugin |2.9|3.0.0| | > Version 21 added net.nicoulaj.maven.plugins:checksum-maven-plugin which > introduced SHA512 checksum instead of SHA1. Should verify if we can rely on > that for releases or breaks our current processes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21547) Precommit uses master flaky list for other branches
[
https://issues.apache.org/jira/browse/HBASE-21547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732905#comment-16732905
]
Hudson commented on HBASE-21547:
Results for branch branch-1
[build #617 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/617/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/617//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/617//console].
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/617//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Precommit uses master flaky list for other branches
> ---
>
> Key: HBASE-21547
> URL: https://issues.apache.org/jira/browse/HBASE-21547
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.2.0, 1.2.10, 1.4.10, 2.1.3, 2.0.5, 1.3.4
>
> Attachments: HBASE-21547.master.001.patch,
> HBASE-21547.master.002.patch
>
>
> Precommit job downloads the flaky exclude list for master branch when the
> uploaded patch file is made for different branches.
> As an example check
> [https://builds.apache.org/job/PreCommit-HBASE-Build/15192] which was against
> branch-1 but the unit test downloaded master's flaky list.
> {noformat}
> 15:26:05 [Tue Dec 4 14:26:04 UTC 2018 INFO]: Personality: patch unit
> 15:26:05 [Tue Dec 4 14:26:04 UTC 2018 INFO]:
> EXCLUDE_TESTS_URL=https://builds.apache.org/job/HBase-Find-Flaky-Tests/job/master/lastSuccessfulBuild/artifact/excludes/
> 15:26:05 [Tue Dec 4 14:26:04 UTC 2018 INFO]: INCLUDE_TESTS_URL=
> 15:26:05 --2018-12-04 14:26:04--
> https://builds.apache.org/job/HBase-Find-Flaky-Tests/job/master/lastSuccessfulBuild/artifact/excludes/
> 15:26:05 Resolving builds.apache.org (builds.apache.org)... 195.201.213.130,
> 2a01:4f8:c0:2cc9::2
> 15:26:05 Connecting to builds.apache.org
> (builds.apache.org)|195.201.213.130|:443... connected.
> 15:26:06 HTTP request sent, awaiting response... 200
> 15:26:06 Length: 866 [application/octet-stream]
> 15:26:06 Saving to: 'excludes'
> 15:26:06
> 15:26:06 0K 100%
> 43.0M=0s
> 15:26:06
> 15:26:06 2018-12-04 14:26:06 (43.0 MB/s) - 'excludes' saved [866/866]
> 15:26:06
> 15:26:09 cd /testptch/hbase/hbase-thrift
> 15:26:09 mvn --batch-mode
> -Dmaven.repo.local=/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/yetus-m2/hbase-branch-1-patch-1
> -DHBasePatchProcess -Dhttps.protocols=TLSv1.2 -PrunAllTests
> -Dtest.exclude.pattern=**/master.cleaner.TestSnapshotFromMaster.java,**/client.TestRestoreSnapshotFromClientAfterSplittingRegions.java,**/regionserver.TestRegionMergeTransactionOnCluster.java,**/client.TestCloneSnapshotFromClientAfterSplittingRegion.java,**/master.assignment.TestAssignmentManager.java,**/master.assignment.TestAMAssignWithRandExec.java,**/client.TestMobCloneSnapshotFromClientAfterSplittingRegion.java,**/regionserver.TestCompactingToCellFlatMapMemStore.java,**/replication.TestReplicationSmallTestsSync.java,**/TestMultiVersions.java,**/client.TestMobRestoreSnapshotFromClientAfterSplittingRegions.java,**/client.TestRestoreSnapshotFromClientWithRegionReplicas.java,**/regionserver.TestRegionServerAbortTimeout.java,**/replication.TestMasterReplication.java,**/backup.TestIncrementalBackupWithBulkLoad.java,**/master.replication.TestRegisterPeerWorkerWhenRestarting.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-thrift.txt 2>&1
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21639) maxHeapUsage value not read properly from config during EntryBuffers initialization
[
https://issues.apache.org/jira/browse/HBASE-21639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732927#comment-16732927
]
Toshihiro Suzuki commented on HBASE-21639:
--
+1
> maxHeapUsage value not read properly from config during EntryBuffers
> initialization
> ---
>
> Key: HBASE-21639
> URL: https://issues.apache.org/jira/browse/HBASE-21639
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1, 2.1.0
>Reporter: Bo Cui
>Assignee: Pankaj Kumar
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: HBASE-21639.001.patch
>
>
>
> {code:java|title=WALSplitter.java|borderStyle=solid}
> entryBuffers = new EntryBuffers(controller,
> this.conf.getInt("hbase.regionserver.hlog.splitlog.buffersize", 128 * 1024 *
> 1024),
> splitWriterCreationBounded);
> {code}
> In above case, EntryBuffers can't support maxHeapUsage in GB size.
> The parameter type of the new EntryBuffers() is long, but the conf max value
> is INT.MAX.
> this is wrong？it should be getLong？
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21588) Procedure v2 wal splitting implementation
[
https://issues.apache.org/jira/browse/HBASE-21588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732938#comment-16732938
]
Jingyun Tian commented on HBASE-21588:
--
[~zghaobac] runs 10 times in straight and I met this problem. There is a thread
stucks when shut down the cluster
{code}
"regionserver/localhost:0.procedureResultReporter" #511 daemon prio=5 os_prio=0
tid=0x7f3cf0073800 nid=0x31c4 runnable [0x7f3bdafca000]
java.lang.Thread.State: RUNNABLE
at
org.apache.hadoop.hbase.regionserver.HRegionServer.reportProcedureDone(HRegionServer.java:3824)
at
org.apache.hadoop.hbase.regionserver.RemoteProcedureResultReporter.run(RemoteProcedureResultReporter.java:92)
{code}
> Procedure v2 wal splitting implementation
> -
>
> Key: HBASE-21588
> URL: https://issues.apache.org/jira/browse/HBASE-21588
> Project: HBase
> Issue Type: Sub-task
>Reporter: Jingyun Tian
>Assignee: Jingyun Tian
>Priority: Major
> Attachments: HBASE-21588.master.003.patch,
> HBASE-21588.master.004.patch, HBASE-21588.master.005.patch,
> HBASE-21588.master.006.patch, HBASE-21588.master.007.patch,
> HBASE-21588.master.008.patch, HBASE-21588.master.009.patch,
> HBASE-21588.master.010.patch, HBASE-21588.master.011.patch,
> HBASE-21588.master.012.patch, HBASE-21588.master.013.patch,
> HBASE-21588.master.014.patch, HBASE-21588.master.015.patch,
> HBASE-21588.master.016.patch, HBASE-21588.master.017.patch,
> HBASE-21588.master.018.patch, HBASE-21588.master.018.patch,
> HBASE-21588.master.019.patch
>
>
> create a sub task to submit the implementation of procedure v2 wal splitting
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21257) misspelled words.[occured -> occurred]
[ https://issues.apache.org/jira/browse/HBASE-21257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732939#comment-16732939 ] Toshihiro Suzuki commented on HBASE-21257: -- +1 > misspelled words.[occured -> occurred] > -- > > Key: HBASE-21257 > URL: https://issues.apache.org/jira/browse/HBASE-21257 > Project: HBase > Issue Type: Bug >Reporter: zhanggangxue >Priority: Trivial > Labels: occured, occurred, typo > Attachments: 0001-misspelled-words.-occured-occurred.patch > > > I found some spelling errors on the master Branch.Found in [misspelled > words|https://github.com/apache/hbase/pull/91] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21667) Move to latest ASF Parent POM
[ https://issues.apache.org/jira/browse/HBASE-21667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732946#comment-16732946 ] Peter Somogyi commented on HBASE-21667: --- I can't find explicit requirement that we need to set it but most Apache project use it (e.g. Phoenix, Accumulo, Ozzie set it, but Hadoop for instance does not). The main benefit is parent pom sets [1] and defines 'apache-release' profile that we rely on for publishing releases. So basically the advantage is we don't need to have the profile defined in our main pom.xml. [1] [https://www.apache.org/dev/publishing-maven-artifacts.html#adjust-maven] [~busbey]: Do you know if parent pom is required by ASF policies? > Move to latest ASF Parent POM > - > > Key: HBASE-21667 > URL: https://issues.apache.org/jira/browse/HBASE-21667 > Project: HBase > Issue Type: Improvement >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Minor > Fix For: 3.0.0, 2.2.0 > > > Currently HBase depends on version 18 which was released on 2016-05-18. > Version 21 was released in August 2018. > Relevant dependency upgrades > > ||Name||Currently used version||New version||Notes|| > |surefire.version|2.21.0|2.22.0| | > |maven-compiler-plugin|3.6.1|3.7| | > |maven-dependency-plugin|3.0.1|3.1.1| | > |maven-jar-plugin|3.0.0|3.0.2| | > |maven-javadoc-plugin|3.0.0|3.0.1| | > |maven-resources-plugin|2.7|3.1.0| | > |maven-site-plugin|3.4|3.7.1|Currently not relying on ASF version. See: > HBASE-18333| > |maven-source-plugin|3.0.0|3.0.1| | > |maven-shade-plugin|3.0.0|3.1.1|Newly added to ASF pom| > |maven-clean-plugin|3.0.0|3.1.0| | > |maven-project-info-reports-plugin |2.9|3.0.0| | > Version 21 added net.nicoulaj.maven.plugins:checksum-maven-plugin which > introduced SHA512 checksum instead of SHA1. Should verify if we can rely on > that for releases or breaks our current processes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21667) Move to latest ASF Parent POM
[ https://issues.apache.org/jira/browse/HBASE-21667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732970#comment-16732970 ] Duo Zhang commented on HBASE-21667: --- OK, then let's upgrade it... > Move to latest ASF Parent POM > - > > Key: HBASE-21667 > URL: https://issues.apache.org/jira/browse/HBASE-21667 > Project: HBase > Issue Type: Improvement >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Minor > Fix For: 3.0.0, 2.2.0 > > > Currently HBase depends on version 18 which was released on 2016-05-18. > Version 21 was released in August 2018. > Relevant dependency upgrades > > ||Name||Currently used version||New version||Notes|| > |surefire.version|2.21.0|2.22.0| | > |maven-compiler-plugin|3.6.1|3.7| | > |maven-dependency-plugin|3.0.1|3.1.1| | > |maven-jar-plugin|3.0.0|3.0.2| | > |maven-javadoc-plugin|3.0.0|3.0.1| | > |maven-resources-plugin|2.7|3.1.0| | > |maven-site-plugin|3.4|3.7.1|Currently not relying on ASF version. See: > HBASE-18333| > |maven-source-plugin|3.0.0|3.0.1| | > |maven-shade-plugin|3.0.0|3.1.1|Newly added to ASF pom| > |maven-clean-plugin|3.0.0|3.1.0| | > |maven-project-info-reports-plugin |2.9|3.0.0| | > Version 21 added net.nicoulaj.maven.plugins:checksum-maven-plugin which > introduced SHA512 checksum instead of SHA1. Should verify if we can rely on > that for releases or breaks our current processes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21135) Build fails on windows as it fails to parse windows path during license check
[
https://issues.apache.org/jira/browse/HBASE-21135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733015#comment-16733015
]
Y. SREENIVASULU REDDY commented on HBASE-21135:
---
this problem is facing in the branch-1 also.
> Build fails on windows as it fails to parse windows path during license check
> -
>
> Key: HBASE-21135
> URL: https://issues.apache.org/jira/browse/HBASE-21135
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0, 2.1.1
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21135.master.001.patch
>
>
> License check via enforce plugin throws following error during build on
> windows:
> {code:java}
> Sourced file: inline evaluation of: ``File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-ar . . . '' Token
> Parsing Error: Lexical error at line 1, column 29. Encountered: "D" (68),
> after : "\"D:\\": {code}
> Complete stacktrace with command
> {code:java}
> mvn clean install -DskipTests -X
> {code}
> is as follows:
> {noformat}
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (check-aggregate-license) @
> hbase-shaded ---
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce from plugin
> realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1,
> parent: sun.misc.Launcher$AppClassLoader@55f96302]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce' with basic
> configurator -->
> [DEBUG] (s) fail = true
> [DEBUG] (s) failFast = false
> [DEBUG] (f) ignoreCache = false
> [DEBUG] (f) mojoExecution =
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce {execution:
> check-aggregate-license}
> [DEBUG] (s) project = MavenProject:
> org.apache.hbase:hbase-shaded:2.1.1-SNAPSHOT @
> D:\DS\HBase_2\hbase\hbase-shaded\pom.xml
> [DEBUG] (s) condition = File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] (s) message = License errors detected, for more detail find ERROR in
>
> D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE
> [DEBUG] (s) rules =
> [org.apache.maven.plugins.enforcer.EvaluateBeanshell@7e307087]
> [DEBUG] (s) session = org.apache.maven.execution.MavenSession@5e1218b4
> [DEBUG] (s) skip = false
> [DEBUG] -- end configuration --
> [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.EvaluateBeanshell
> [DEBUG] Echo condition : File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] Echo script : File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Couldn't evaluate
> condition: File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
>
[jira] [Created] (HBASE-21668) SCM fetch times out for nightlies
Peter Somogyi created HBASE-21668:
-
Summary: SCM fetch times out for nightlies
Key: HBASE-21668
URL: https://issues.apache.org/jira/browse/HBASE-21668
Project: HBase
Issue Type: Bug
Reporter: Peter Somogyi
Many of the nightly builds are failing with timeout on checkout stage with git
fetch command. The default timeout is 2 minutes. We could either increase the
timeout or use shallow clone that would also reduce the used space.
Error from console output:
{noformat}
08:48:10 Cloning the remote Git repository
08:48:10 Cloning with configured refspecs honoured and without tags
Cloning repository https://git.apache.org/hbase.git
> git init
> /home/jenkins/jenkins-slave/workspace/HBase_Nightly_master-4PMG3QPNOXT5YRQZS7HMZP3GLNX6XSF6DVHYXYIB5BWQ75VW3CPA@2/component
> # timeout=10
Fetching upstream changes from https://git.apache.org/hbase.git
> git --version # timeout=10
> git fetch --no-tags --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*
08:50:15 ERROR: Error cloning remote repo 'origin'
08:50:15 hudson.plugins.git.GitException: Command "git fetch --no-tags
--progress https://git.apache.org/hbase.git
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
08:50:15 stdout:
08:50:15 stderr: fatal: unable to access 'https://git.apache.org/hbase.git/':
Failed to connect to git.apache.org port 443: Connection timed out{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21588) Procedure v2 wal splitting implementation
[
https://issues.apache.org/jira/browse/HBASE-21588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733022#comment-16733022
]
Hadoop QA commented on HBASE-21588:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
12s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 7 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
24s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
9s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
5s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
55s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s{color} | {color:green} The patch passed checkstyle in hbase-protocol-shaded
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
23s{color} | {color:green} The patch passed checkstyle in hbase-common {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
11s{color} | {color:green} hbase-server: The patch generated 0 new + 271
unchanged - 1 fixed = 271 total (was 272) {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
6s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 42s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
1m 32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
59s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
33s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
44s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}127m
36s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
17s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}183m 12s{color} |
{color
[jira] [Updated] (HBASE-21657) PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% scan case.
[ https://issues.apache.org/jira/browse/HBASE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-21657: - Attachment: hbase2.0.4-ssd-scan-traces.svg > PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% > scan case. > > > Key: HBASE-21657 > URL: https://issues.apache.org/jira/browse/HBASE-21657 > Project: HBase > Issue Type: Bug > Components: Performance >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21657.v1.patch, HBASE-21657.v2.patch, > hbase2.0.4-ssd-scan-traces.svg, hbase20-ssd-100-scan-traces.svg > > > We are evaluating the performance of branch-2, and find that the throughput > of scan in SSD cluster is almost the same as HDD cluster. so I made a > FlameGraph on RS, and found that the > PrivateCellUtil#estimatedSerializedSizeOf cost about 29% cpu, Obviously, it > has been the bottleneck in 100% scan case. > See the [^hbase20-ssd-100-scan-traces.svg] > BTW, in our XiaoMi branch, we introduce a > HRegion#updateReadRequestsByCapacityUnitPerSecond to sum up the size of cells > (for metric monitor), so it seems the performance loss was amplified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21657) PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% scan case.
[ https://issues.apache.org/jira/browse/HBASE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-21657: - Attachment: HBASE-21657.v2.patch > PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% > scan case. > > > Key: HBASE-21657 > URL: https://issues.apache.org/jira/browse/HBASE-21657 > Project: HBase > Issue Type: Bug > Components: Performance >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21657.v1.patch, HBASE-21657.v2.patch, > hbase2.0.4-ssd-scan-traces.svg, hbase20-ssd-100-scan-traces.svg > > > We are evaluating the performance of branch-2, and find that the throughput > of scan in SSD cluster is almost the same as HDD cluster. so I made a > FlameGraph on RS, and found that the > PrivateCellUtil#estimatedSerializedSizeOf cost about 29% cpu, Obviously, it > has been the bottleneck in 100% scan case. > See the [^hbase20-ssd-100-scan-traces.svg] > BTW, in our XiaoMi branch, we introduce a > HRegion#updateReadRequestsByCapacityUnitPerSecond to sum up the size of cells > (for metric monitor), so it seems the performance loss was amplified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21135) Build fails on windows as it fails to parse windows path during license check
[
https://issues.apache.org/jira/browse/HBASE-21135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733048#comment-16733048
]
Nihal Jain commented on HBASE-21135:
[~sreenivasulureddy] does this patch fix the issue?
> Build fails on windows as it fails to parse windows path during license check
> -
>
> Key: HBASE-21135
> URL: https://issues.apache.org/jira/browse/HBASE-21135
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0, 2.1.1
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21135.master.001.patch
>
>
> License check via enforce plugin throws following error during build on
> windows:
> {code:java}
> Sourced file: inline evaluation of: ``File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-ar . . . '' Token
> Parsing Error: Lexical error at line 1, column 29. Encountered: "D" (68),
> after : "\"D:\\": {code}
> Complete stacktrace with command
> {code:java}
> mvn clean install -DskipTests -X
> {code}
> is as follows:
> {noformat}
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (check-aggregate-license) @
> hbase-shaded ---
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce from plugin
> realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1,
> parent: sun.misc.Launcher$AppClassLoader@55f96302]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce' with basic
> configurator -->
> [DEBUG] (s) fail = true
> [DEBUG] (s) failFast = false
> [DEBUG] (f) ignoreCache = false
> [DEBUG] (f) mojoExecution =
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce {execution:
> check-aggregate-license}
> [DEBUG] (s) project = MavenProject:
> org.apache.hbase:hbase-shaded:2.1.1-SNAPSHOT @
> D:\DS\HBase_2\hbase\hbase-shaded\pom.xml
> [DEBUG] (s) condition = File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] (s) message = License errors detected, for more detail find ERROR in
>
> D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE
> [DEBUG] (s) rules =
> [org.apache.maven.plugins.enforcer.EvaluateBeanshell@7e307087]
> [DEBUG] (s) session = org.apache.maven.execution.MavenSession@5e1218b4
> [DEBUG] (s) skip = false
> [DEBUG] -- end configuration --
> [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.EvaluateBeanshell
> [DEBUG] Echo condition : File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] Echo script : File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Couldn't evaluate
> condition: File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Bea
[jira] [Updated] (HBASE-21657) PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% scan case.
[ https://issues.apache.org/jira/browse/HBASE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-21657: - Attachment: hbase2.0.4-ssd-scan-traces.2.svg > PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% > scan case. > > > Key: HBASE-21657 > URL: https://issues.apache.org/jira/browse/HBASE-21657 > Project: HBase > Issue Type: Bug > Components: Performance >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21657.v1.patch, HBASE-21657.v2.patch, > hbase2.0.4-ssd-scan-traces.2.svg, hbase2.0.4-ssd-scan-traces.svg, > hbase20-ssd-100-scan-traces.svg > > > We are evaluating the performance of branch-2, and find that the throughput > of scan in SSD cluster is almost the same as HDD cluster. so I made a > FlameGraph on RS, and found that the > PrivateCellUtil#estimatedSerializedSizeOf cost about 29% cpu, Obviously, it > has been the bottleneck in 100% scan case. > See the [^hbase20-ssd-100-scan-traces.svg] > BTW, in our XiaoMi branch, we introduce a > HRegion#updateReadRequestsByCapacityUnitPerSecond to sum up the size of cells > (for metric monitor), so it seems the performance loss was amplified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21668) SCM fetch times out for nightlies
[
https://issues.apache.org/jira/browse/HBASE-21668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi updated HBASE-21668:
--
Attachment: HBASE-21668.master.001.patch
> SCM fetch times out for nightlies
> -
>
> Key: HBASE-21668
> URL: https://issues.apache.org/jira/browse/HBASE-21668
> Project: HBase
> Issue Type: Bug
>Reporter: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-21668.master.001.patch
>
>
> Many of the nightly builds are failing with timeout on checkout stage with
> git fetch command. The default timeout is 2 minutes. We could either increase
> the timeout or use shallow clone that would also reduce the used space.
> Error from console output:
> {noformat}
> 08:48:10 Cloning the remote Git repository
> 08:48:10 Cloning with configured refspecs honoured and without tags
> Cloning repository https://git.apache.org/hbase.git
> > git init
> /home/jenkins/jenkins-slave/workspace/HBase_Nightly_master-4PMG3QPNOXT5YRQZS7HMZP3GLNX6XSF6DVHYXYIB5BWQ75VW3CPA@2/component
> # timeout=10
> Fetching upstream changes from https://git.apache.org/hbase.git
> > git --version # timeout=10
> > git fetch --no-tags --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*
> 08:50:15 ERROR: Error cloning remote repo 'origin'
> 08:50:15 hudson.plugins.git.GitException: Command "git fetch --no-tags
> --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> 08:50:15 stdout:
> 08:50:15 stderr: fatal: unable to access 'https://git.apache.org/hbase.git/':
> Failed to connect to git.apache.org port 443: Connection timed out{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21668) SCM fetch times out for nightlies
[
https://issues.apache.org/jira/browse/HBASE-21668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi updated HBASE-21668:
--
Assignee: Peter Somogyi
Status: Patch Available (was: Open)
> SCM fetch times out for nightlies
> -
>
> Key: HBASE-21668
> URL: https://issues.apache.org/jira/browse/HBASE-21668
> Project: HBase
> Issue Type: Bug
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-21668.master.001.patch
>
>
> Many of the nightly builds are failing with timeout on checkout stage with
> git fetch command. The default timeout is 2 minutes. We could either increase
> the timeout or use shallow clone that would also reduce the used space.
> Error from console output:
> {noformat}
> 08:48:10 Cloning the remote Git repository
> 08:48:10 Cloning with configured refspecs honoured and without tags
> Cloning repository https://git.apache.org/hbase.git
> > git init
> /home/jenkins/jenkins-slave/workspace/HBase_Nightly_master-4PMG3QPNOXT5YRQZS7HMZP3GLNX6XSF6DVHYXYIB5BWQ75VW3CPA@2/component
> # timeout=10
> Fetching upstream changes from https://git.apache.org/hbase.git
> > git --version # timeout=10
> > git fetch --no-tags --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*
> 08:50:15 ERROR: Error cloning remote repo 'origin'
> 08:50:15 hudson.plugins.git.GitException: Command "git fetch --no-tags
> --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> 08:50:15 stdout:
> 08:50:15 stderr: fatal: unable to access 'https://git.apache.org/hbase.git/':
> Failed to connect to git.apache.org port 443: Connection timed out{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21657) PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% scan case.
[ https://issues.apache.org/jira/browse/HBASE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733059#comment-16733059 ] Zheng Hu commented on HBASE-21657: -- I made an performance comparasion between hbase2.0.4 without patch.v2 and hbase2.0.4 with patch.v2: || - || QPS| FlameGraph| |HBase2.0.4 without patch.v2|14392.7 ops/sec| [^hbase2.0.4-ssd-scan-traces.svg] | |HBase2.0.4 with patch.v2| 9979.8 ops/sec| [^hbase2.0.4-ssd-scan-traces.2.svg] | Later, I'll provide more details about the QPS & latency. > PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% > scan case. > > > Key: HBASE-21657 > URL: https://issues.apache.org/jira/browse/HBASE-21657 > Project: HBase > Issue Type: Bug > Components: Performance >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21657.v1.patch, HBASE-21657.v2.patch, > hbase2.0.4-ssd-scan-traces.2.svg, hbase2.0.4-ssd-scan-traces.svg, > hbase20-ssd-100-scan-traces.svg > > > We are evaluating the performance of branch-2, and find that the throughput > of scan in SSD cluster is almost the same as HDD cluster. so I made a > FlameGraph on RS, and found that the > PrivateCellUtil#estimatedSerializedSizeOf cost about 29% cpu, Obviously, it > has been the bottleneck in 100% scan case. > See the [^hbase20-ssd-100-scan-traces.svg] > BTW, in our XiaoMi branch, we introduce a > HRegion#updateReadRequestsByCapacityUnitPerSecond to sum up the size of cells > (for metric monitor), so it seems the performance loss was amplified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21657) PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% scan case.
[
https://issues.apache.org/jira/browse/HBASE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733059#comment-16733059
]
Zheng Hu edited comment on HBASE-21657 at 1/3/19 2:04 PM:
--
I made an performance comparasion between hbase2.0.4 without patch.v2 and
hbase2.0.4 with patch.v2:
|| Comparision || QPS| FlameGraph|
|HBase2.0.4 without patch.v2|14392.7 ops/sec| [^hbase2.0.4-ssd-scan-traces.svg]
|
|HBase2.0.4 with patch.v2| 9979.8 ops/sec| [^hbase2.0.4-ssd-scan-traces.2.svg]
|
Later, I'll provide more details about the QPS & latency.
BTW, my testing environment were:
5 Nodes : 12*800G SSD / 24 Core / 128GB memory (50G onheap + 50G offheap for
each RS, and allocated 36G for BucketCache).
and I used the YCSB 100% scan workload (by default, the ycsb will generate a
scan with limit in [1...1000] )
{code}
table=ycsb-test
columnfamily=C
recordcount=1
operationcount=1
workload=com.yahoo.ycsb.workloads.CoreWorkload
fieldlength=100
fieldcount=1
clientbuffering=true
readallfields=true
writeallfields=true
readproportion=0
updateproportion=0
scanproportion=1.0
insertproportion=0
requestdistribution=zipfian
{code}
was (Author: openinx):
I made an performance comparasion between hbase2.0.4 without patch.v2 and
hbase2.0.4 with patch.v2:
|| - || QPS| FlameGraph|
|HBase2.0.4 without patch.v2|14392.7 ops/sec| [^hbase2.0.4-ssd-scan-traces.svg]
|
|HBase2.0.4 with patch.v2| 9979.8 ops/sec| [^hbase2.0.4-ssd-scan-traces.2.svg]
|
Later, I'll provide more details about the QPS & latency.
> PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100%
> scan case.
>
>
> Key: HBASE-21657
> URL: https://issues.apache.org/jira/browse/HBASE-21657
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21657.v1.patch, HBASE-21657.v2.patch,
> hbase2.0.4-ssd-scan-traces.2.svg, hbase2.0.4-ssd-scan-traces.svg,
> hbase20-ssd-100-scan-traces.svg
>
>
> We are evaluating the performance of branch-2, and find that the throughput
> of scan in SSD cluster is almost the same as HDD cluster. so I made a
> FlameGraph on RS, and found that the
> PrivateCellUtil#estimatedSerializedSizeOf cost about 29% cpu, Obviously, it
> has been the bottleneck in 100% scan case.
> See the [^hbase20-ssd-100-scan-traces.svg]
> BTW, in our XiaoMi branch, we introduce a
> HRegion#updateReadRequestsByCapacityUnitPerSecond to sum up the size of cells
> (for metric monitor), so it seems the performance loss was amplified.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21657) PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% scan case.
[
https://issues.apache.org/jira/browse/HBASE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733059#comment-16733059
]
Zheng Hu edited comment on HBASE-21657 at 1/3/19 2:06 PM:
--
I made an performance comparasion between hbase2.0.4 without patch.v2 and
hbase2.0.4 with patch.v2:
|| Comparision || QPS| FlameGraph| L2 cacheHitRatio|
|HBase2.0.4 without patch.v2|14392.7 ops/sec| [^hbase2.0.4-ssd-scan-traces.svg]
| ~95%|
|HBase2.0.4 with patch.v2| 9979.8 ops/sec| [^hbase2.0.4-ssd-scan-traces.2.svg]
| ~95% |
Later, I'll provide more details about the QPS & latency.
BTW, my testing environment were:
5 Nodes : 12*800G SSD / 24 Core / 128GB memory (50G onheap + 50G offheap for
each RS, and allocated 36G for BucketCache).
and I used the YCSB 100% scan workload (by default, the ycsb will generate a
scan with limit in [1...1000] )
{code}
table=ycsb-test
columnfamily=C
recordcount=1
operationcount=1
workload=com.yahoo.ycsb.workloads.CoreWorkload
fieldlength=100
fieldcount=1
clientbuffering=true
readallfields=true
writeallfields=true
readproportion=0
updateproportion=0
scanproportion=1.0
insertproportion=0
requestdistribution=zipfian
{code}
was (Author: openinx):
I made an performance comparasion between hbase2.0.4 without patch.v2 and
hbase2.0.4 with patch.v2:
|| Comparision || QPS| FlameGraph|
|HBase2.0.4 without patch.v2|14392.7 ops/sec| [^hbase2.0.4-ssd-scan-traces.svg]
|
|HBase2.0.4 with patch.v2| 9979.8 ops/sec| [^hbase2.0.4-ssd-scan-traces.2.svg]
|
Later, I'll provide more details about the QPS & latency.
BTW, my testing environment were:
5 Nodes : 12*800G SSD / 24 Core / 128GB memory (50G onheap + 50G offheap for
each RS, and allocated 36G for BucketCache).
and I used the YCSB 100% scan workload (by default, the ycsb will generate a
scan with limit in [1...1000] )
{code}
table=ycsb-test
columnfamily=C
recordcount=1
operationcount=1
workload=com.yahoo.ycsb.workloads.CoreWorkload
fieldlength=100
fieldcount=1
clientbuffering=true
readallfields=true
writeallfields=true
readproportion=0
updateproportion=0
scanproportion=1.0
insertproportion=0
requestdistribution=zipfian
{code}
> PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100%
> scan case.
>
>
> Key: HBASE-21657
> URL: https://issues.apache.org/jira/browse/HBASE-21657
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21657.v1.patch, HBASE-21657.v2.patch,
> hbase2.0.4-ssd-scan-traces.2.svg, hbase2.0.4-ssd-scan-traces.svg,
> hbase20-ssd-100-scan-traces.svg
>
>
> We are evaluating the performance of branch-2, and find that the throughput
> of scan in SSD cluster is almost the same as HDD cluster. so I made a
> FlameGraph on RS, and found that the
> PrivateCellUtil#estimatedSerializedSizeOf cost about 29% cpu, Obviously, it
> has been the bottleneck in 100% scan case.
> See the [^hbase20-ssd-100-scan-traces.svg]
> BTW, in our XiaoMi branch, we introduce a
> HRegion#updateReadRequestsByCapacityUnitPerSecond to sum up the size of cells
> (for metric monitor), so it seems the performance loss was amplified.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21668) SCM fetch times out for nightlies
[
https://issues.apache.org/jira/browse/HBASE-21668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733064#comment-16733064
]
Hadoop QA commented on HBASE-21668:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
9s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
0s{color} | {color:blue} Shelldocs was not available. {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:brown} master Compile Tests {color} ||
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
0s{color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
10s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 0m 29s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21668 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12953638/HBASE-21668.master.001.patch
|
| Optional Tests | dupname asflicense shellcheck shelldocs |
| uname | Linux ad6b309d007f 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 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 / 466fa920fe |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| shellcheck | v0.4.4 |
| Max. process+thread count | 47 (vs. ulimit of 1) |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/15457/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> SCM fetch times out for nightlies
> -
>
> Key: HBASE-21668
> URL: https://issues.apache.org/jira/browse/HBASE-21668
> Project: HBase
> Issue Type: Bug
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-21668.master.001.patch
>
>
> Many of the nightly builds are failing with timeout on checkout stage with
> git fetch command. The default timeout is 2 minutes. We could either increase
> the timeout or use shallow clone that would also reduce the used space.
> Error from console output:
> {noformat}
> 08:48:10 Cloning the remote Git repository
> 08:48:10 Cloning with configured refspecs honoured and without tags
> Cloning repository https://git.apache.org/hbase.git
> > git init
> /home/jenkins/jenkins-slave/workspace/HBase_Nightly_master-4PMG3QPNOXT5YRQZS7HMZP3GLNX6XSF6DVHYXYIB5BWQ75VW3CPA@2/component
> # timeout=10
> Fetching upstream changes from https://git.apache.org/hbase.git
> > git --version # timeout=10
> > git fetch --no-tags --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*
> 08:50:15 ERROR: Error cloning remote repo 'origin'
> 08:50:15 hudson.plugins.git.GitException: Command "git fetch --no-tags
> --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> 08:50:15 stdout:
> 08:50:15 stderr: fatal: unable to access 'https://git.apache.org/hbase.git/':
> Failed to connect to git.apache.org port 443: Connection timed out{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21588) Procedure v2 wal splitting implementation
[ https://issues.apache.org/jira/browse/HBASE-21588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-21588: - Attachment: (was: HBASE-21588.master.019.patch) > Procedure v2 wal splitting implementation > - > > Key: HBASE-21588 > URL: https://issues.apache.org/jira/browse/HBASE-21588 > Project: HBase > Issue Type: Sub-task >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Attachments: HBASE-21588.master.003.patch, > HBASE-21588.master.004.patch, HBASE-21588.master.005.patch, > HBASE-21588.master.006.patch, HBASE-21588.master.007.patch, > HBASE-21588.master.008.patch, HBASE-21588.master.009.patch, > HBASE-21588.master.010.patch, HBASE-21588.master.011.patch, > HBASE-21588.master.012.patch, HBASE-21588.master.013.patch, > HBASE-21588.master.014.patch, HBASE-21588.master.015.patch, > HBASE-21588.master.016.patch, HBASE-21588.master.017.patch, > HBASE-21588.master.018.patch, HBASE-21588.master.018.patch > > > create a sub task to submit the implementation of procedure v2 wal splitting -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21512) Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
[
https://issues.apache.org/jira/browse/HBASE-21512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733085#comment-16733085
]
Hudson commented on HBASE-21512:
Results for branch HBASE-21512
[build #38 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/38/]:
(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/HBASE-21512/38//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/HBASE-21512/38//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/HBASE-21512/38//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
> --
>
> Key: HBASE-21512
> URL: https://issues.apache.org/jira/browse/HBASE-21512
> Project: HBase
> Issue Type: Umbrella
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
>
> At least for the RSProcedureDispatcher, with CompletableFuture we do not need
> to set a delay and use a thread pool any more, which could reduce the
> resource usage and also the latency.
> Once this is done, I think we can remove the ClusterConnection completely,
> and start to rewrite the old sync client based on the async client, which
> could reduce the code base a lot for our client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21159) Add shell command to switch throttle on or off
[
https://issues.apache.org/jira/browse/HBASE-21159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733087#comment-16733087
]
Hadoop QA commented on HBASE-21159:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
9s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color: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 4 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
26s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
38s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
13s{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
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 4m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
10s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
12s{color} | {color:red} The patch generated 6 new + 149 unchanged - 2 fixed =
155 total (was 151) {color} |
| {color:orange}-0{color} | {color:orange} ruby-lint {color} | {color:orange}
0m 9s{color} | {color:orange} The patch generated 14 new + 270 unchanged - 0
fixed = 284 total (was 270) {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
35s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 58s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
1m 58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
12s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
34s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
4s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}144m
34s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m
16s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
27s{color} | {color:green} The patch does not generate ASF
[jira] [Commented] (HBASE-21135) Build fails on windows as it fails to parse windows path during license check
[
https://issues.apache.org/jira/browse/HBASE-21135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733092#comment-16733092
]
Y. SREENIVASULU REDDY commented on HBASE-21135:
---
[~nihaljain.cs]
Yes this patch is fixing the issue.
> Build fails on windows as it fails to parse windows path during license check
> -
>
> Key: HBASE-21135
> URL: https://issues.apache.org/jira/browse/HBASE-21135
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0, 2.1.1
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21135.master.001.patch
>
>
> License check via enforce plugin throws following error during build on
> windows:
> {code:java}
> Sourced file: inline evaluation of: ``File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-ar . . . '' Token
> Parsing Error: Lexical error at line 1, column 29. Encountered: "D" (68),
> after : "\"D:\\": {code}
> Complete stacktrace with command
> {code:java}
> mvn clean install -DskipTests -X
> {code}
> is as follows:
> {noformat}
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (check-aggregate-license) @
> hbase-shaded ---
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce from plugin
> realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1,
> parent: sun.misc.Launcher$AppClassLoader@55f96302]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce' with basic
> configurator -->
> [DEBUG] (s) fail = true
> [DEBUG] (s) failFast = false
> [DEBUG] (f) ignoreCache = false
> [DEBUG] (f) mojoExecution =
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce {execution:
> check-aggregate-license}
> [DEBUG] (s) project = MavenProject:
> org.apache.hbase:hbase-shaded:2.1.1-SNAPSHOT @
> D:\DS\HBase_2\hbase\hbase-shaded\pom.xml
> [DEBUG] (s) condition = File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] (s) message = License errors detected, for more detail find ERROR in
>
> D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE
> [DEBUG] (s) rules =
> [org.apache.maven.plugins.enforcer.EvaluateBeanshell@7e307087]
> [DEBUG] (s) session = org.apache.maven.execution.MavenSession@5e1218b4
> [DEBUG] (s) skip = false
> [DEBUG] -- end configuration --
> [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.EvaluateBeanshell
> [DEBUG] Echo condition : File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] Echo script : File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Couldn't evaluate
> condition: File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
>
[jira] [Commented] (HBASE-21665) OfflineMetaRepair tool fails with NPE
[
https://issues.apache.org/jira/browse/HBASE-21665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733108#comment-16733108
]
Pankaj Kumar commented on HBASE-21665:
--
{quote}Do folks totally destroy their hbase:meta tables and need to rebuild
from scratch?
{quote}
Not exactly, but in case of cluster upgrade or meta Hfile curroption we do use
this tool to rebuild the meta and start the master, so that region will be
assigned and old data become available for the client operations.
{quote}Could we ask the master to do a hbase:meta rebuild for us via hbck2. It
might have more info than just layout in hdfs?
{quote}
This would be better solution if we are planning to drop .regioninfo and
tableinfo files from region and table directory respectively because currently
OfflineMetaRepair totally depends on them.
{quote}In your scenario, could you not copy the hbase1 meta table too? You'd
need to upgrade it so the extra column family got added before you started up
hbase2?
{quote}
We cant copy meta table as we dont the extra CF which were added later in
1.4.x + versions and upgrading to 1.4.x will be big task for us currently.
> OfflineMetaRepair tool fails with NPE
> -
>
> Key: HBASE-21665
> URL: https://issues.apache.org/jira/browse/HBASE-21665
> Project: HBase
> Issue Type: Bug
> Components: hbck
>Affects Versions: 2.1.0, 2.0.0
>Reporter: Pankaj Kumar
>Assignee: Pankaj Kumar
>Priority: Critical
>
> OfflineMetaRepair fails with NPE, execute below command
> hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair -fix
>
> {noformat}
> 2019-01-02 16:22:56,387 INFO [main] regionserver.HRegion: Opened 1588230740;
> next sequenceid=28
> 2019-01-02 16:22:56,459 ERROR [main] hbck.OfflineMetaRepair: Bailed out due
> to:
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.getOrMakeChunk(MemStoreLABImpl.java:335)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.copyCellInto(MemStoreLABImpl.java:193)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.copyCellInto(MemStoreLABImpl.java:115)
> at
> org.apache.hadoop.hbase.regionserver.Segment.maybeCloneWithAllocator(Segment.java:183)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.maybeCloneWithAllocator(AbstractMemStore.java:334)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.doAdd(AbstractMemStore.java:157)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.doAddOrUpsert(AbstractMemStore.java:147)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.add(AbstractMemStore.java:117)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.add(AbstractMemStore.java:111)
> at org.apache.hadoop.hbase.regionserver.HStore.add(HStore.java:750)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.applyToMemStore(HRegion.java:4435)
> at org.apache.hadoop.hbase.regionserver.HRegion.access$500(HRegion.java:228)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.applyFamilyMapToMemStore(HRegion.java:3495)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.lambda$writeMiniBatchOperationsToMemStore$0(HRegion.java:3186)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.visitBatchOperations(HRegion.java:3119)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.writeMiniBatchOperationsToMemStore(HRegion.java:3178)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation.writeMiniBatchOperationsToMemStore(HRegion.java:3660)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutate(HRegion.java:4073)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:4006)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3937)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3928)
> at org.apache.hadoop.hbase.util.HBaseFsck.rebuildMeta(HBaseFsck.java:1665)
> at
> org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair.main(OfflineMetaRepair.java:121)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21665) OfflineMetaRepair tool fails with NPE
[
https://issues.apache.org/jira/browse/HBASE-21665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733118#comment-16733118
]
Pankaj Kumar commented on HBASE-21665:
--
{quote}Oh, we should make a call though. Currently failing w/ a NPE is not
right.
{quote}
We can fix NPE by setting false to hbase.hregion.memstore.mslab.enabled. Meta
will be rebuild but of no use, none of the non-meta/user table regions will
become online as we are skipping them during meta load.
> OfflineMetaRepair tool fails with NPE
> -
>
> Key: HBASE-21665
> URL: https://issues.apache.org/jira/browse/HBASE-21665
> Project: HBase
> Issue Type: Bug
> Components: hbck
>Affects Versions: 2.1.0, 2.0.0
>Reporter: Pankaj Kumar
>Assignee: Pankaj Kumar
>Priority: Critical
>
> OfflineMetaRepair fails with NPE, execute below command
> hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair -fix
>
> {noformat}
> 2019-01-02 16:22:56,387 INFO [main] regionserver.HRegion: Opened 1588230740;
> next sequenceid=28
> 2019-01-02 16:22:56,459 ERROR [main] hbck.OfflineMetaRepair: Bailed out due
> to:
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.getOrMakeChunk(MemStoreLABImpl.java:335)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.copyCellInto(MemStoreLABImpl.java:193)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.copyCellInto(MemStoreLABImpl.java:115)
> at
> org.apache.hadoop.hbase.regionserver.Segment.maybeCloneWithAllocator(Segment.java:183)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.maybeCloneWithAllocator(AbstractMemStore.java:334)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.doAdd(AbstractMemStore.java:157)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.doAddOrUpsert(AbstractMemStore.java:147)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.add(AbstractMemStore.java:117)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.add(AbstractMemStore.java:111)
> at org.apache.hadoop.hbase.regionserver.HStore.add(HStore.java:750)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.applyToMemStore(HRegion.java:4435)
> at org.apache.hadoop.hbase.regionserver.HRegion.access$500(HRegion.java:228)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.applyFamilyMapToMemStore(HRegion.java:3495)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.lambda$writeMiniBatchOperationsToMemStore$0(HRegion.java:3186)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.visitBatchOperations(HRegion.java:3119)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.writeMiniBatchOperationsToMemStore(HRegion.java:3178)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation.writeMiniBatchOperationsToMemStore(HRegion.java:3660)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutate(HRegion.java:4073)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:4006)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3937)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3928)
> at org.apache.hadoop.hbase.util.HBaseFsck.rebuildMeta(HBaseFsck.java:1665)
> at
> org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair.main(OfflineMetaRepair.java:121)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21628) memory leak risk when ClientAsyncPrefetchScanner not close
[ https://issues.apache.org/jira/browse/HBASE-21628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] cong.han updated HBASE-21628: - Issue Type: Bug (was: Improvement) > memory leak risk when ClientAsyncPrefetchScanner not close > -- > > Key: HBASE-21628 > URL: https://issues.apache.org/jira/browse/HBASE-21628 > Project: HBase > Issue Type: Bug >Reporter: cong.han >Assignee: cong.han >Priority: Major > Attachments: HBASE-21328-v1.patch, HBASE-21628-v2.patch, > HBASE-21628-v3.patch, HBASE-21628-v4.patch, HBASE-21628-v5.patch > > > When we use ClientAsyncPrefetchScanner and we do two things below > 1 Forgot to call close() method > 2 The result are not full fetched > The prefetch thread will not exit and leave a memory leak risk. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21628) memory leak risk when ClientAsyncPrefetchScanner not close
[ https://issues.apache.org/jira/browse/HBASE-21628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733136#comment-16733136 ] cong.han commented on HBASE-21628: -- Change type to BUG,It's more like a potential bug. > memory leak risk when ClientAsyncPrefetchScanner not close > -- > > Key: HBASE-21628 > URL: https://issues.apache.org/jira/browse/HBASE-21628 > Project: HBase > Issue Type: Bug >Reporter: cong.han >Assignee: cong.han >Priority: Major > Attachments: HBASE-21328-v1.patch, HBASE-21628-v2.patch, > HBASE-21628-v3.patch, HBASE-21628-v4.patch, HBASE-21628-v5.patch > > > When we use ClientAsyncPrefetchScanner and we do two things below > 1 Forgot to call close() method > 2 The result are not full fetched > The prefetch thread will not exit and leave a memory leak risk. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21573) More sensible client default timeout values
[
https://issues.apache.org/jira/browse/HBASE-21573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733162#comment-16733162
]
Hadoop QA commented on HBASE-21573:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
9s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color: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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
32s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
2s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
15s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 5m
38s{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
37s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
16s{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
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m
2s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 2m
21s{color} | {color:red} root: The patch generated 1 new + 12 unchanged - 2
fixed = 13 total (was 14) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 5m
45s{color} | {color:blue} patch 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
33s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 43s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
20s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}214m
59s{color} | {color:green} root 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}285m 27s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issu
[jira] [Updated] (HBASE-21135) Build fails on windows as it fails to parse windows path during license check
[
https://issues.apache.org/jira/browse/HBASE-21135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-21135:
Labels: cygwin (was: )
> Build fails on windows as it fails to parse windows path during license check
> -
>
> Key: HBASE-21135
> URL: https://issues.apache.org/jira/browse/HBASE-21135
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0, 2.1.1
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Labels: cygwin
> Fix For: 3.0.0
>
> Attachments: HBASE-21135.master.001.patch
>
>
> License check via enforce plugin throws following error during build on
> windows:
> {code:java}
> Sourced file: inline evaluation of: ``File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-ar . . . '' Token
> Parsing Error: Lexical error at line 1, column 29. Encountered: "D" (68),
> after : "\"D:\\": {code}
> Complete stacktrace with command
> {code:java}
> mvn clean install -DskipTests -X
> {code}
> is as follows:
> {noformat}
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (check-aggregate-license) @
> hbase-shaded ---
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce from plugin
> realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1,
> parent: sun.misc.Launcher$AppClassLoader@55f96302]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce' with basic
> configurator -->
> [DEBUG] (s) fail = true
> [DEBUG] (s) failFast = false
> [DEBUG] (f) ignoreCache = false
> [DEBUG] (f) mojoExecution =
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce {execution:
> check-aggregate-license}
> [DEBUG] (s) project = MavenProject:
> org.apache.hbase:hbase-shaded:2.1.1-SNAPSHOT @
> D:\DS\HBase_2\hbase\hbase-shaded\pom.xml
> [DEBUG] (s) condition = File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] (s) message = License errors detected, for more detail find ERROR in
>
> D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE
> [DEBUG] (s) rules =
> [org.apache.maven.plugins.enforcer.EvaluateBeanshell@7e307087]
> [DEBUG] (s) session = org.apache.maven.execution.MavenSession@5e1218b4
> [DEBUG] (s) skip = false
> [DEBUG] -- end configuration --
> [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.EvaluateBeanshell
> [DEBUG] Echo condition : File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] Echo script : File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Couldn't evaluate
> condition: File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
>
[jira] [Updated] (HBASE-21668) SCM fetch times out for nightlies
[
https://issues.apache.org/jira/browse/HBASE-21668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-21668:
Component/s: test
> SCM fetch times out for nightlies
> -
>
> Key: HBASE-21668
> URL: https://issues.apache.org/jira/browse/HBASE-21668
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-21668.master.001.patch
>
>
> Many of the nightly builds are failing with timeout on checkout stage with
> git fetch command. The default timeout is 2 minutes. We could either increase
> the timeout or use shallow clone that would also reduce the used space.
> Error from console output:
> {noformat}
> 08:48:10 Cloning the remote Git repository
> 08:48:10 Cloning with configured refspecs honoured and without tags
> Cloning repository https://git.apache.org/hbase.git
> > git init
> /home/jenkins/jenkins-slave/workspace/HBase_Nightly_master-4PMG3QPNOXT5YRQZS7HMZP3GLNX6XSF6DVHYXYIB5BWQ75VW3CPA@2/component
> # timeout=10
> Fetching upstream changes from https://git.apache.org/hbase.git
> > git --version # timeout=10
> > git fetch --no-tags --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*
> 08:50:15 ERROR: Error cloning remote repo 'origin'
> 08:50:15 hudson.plugins.git.GitException: Command "git fetch --no-tags
> --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> 08:50:15 stdout:
> 08:50:15 stderr: fatal: unable to access 'https://git.apache.org/hbase.git/':
> Failed to connect to git.apache.org port 443: Connection timed out{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21668) SCM fetch times out for nightlies
[
https://issues.apache.org/jira/browse/HBASE-21668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733189#comment-16733189
]
Sean Busbey commented on HBASE-21668:
-
We should ping INFRA before changing things, in case this is a symptom of some
larger issue.
> SCM fetch times out for nightlies
> -
>
> Key: HBASE-21668
> URL: https://issues.apache.org/jira/browse/HBASE-21668
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-21668.master.001.patch
>
>
> Many of the nightly builds are failing with timeout on checkout stage with
> git fetch command. The default timeout is 2 minutes. We could either increase
> the timeout or use shallow clone that would also reduce the used space.
> Error from console output:
> {noformat}
> 08:48:10 Cloning the remote Git repository
> 08:48:10 Cloning with configured refspecs honoured and without tags
> Cloning repository https://git.apache.org/hbase.git
> > git init
> /home/jenkins/jenkins-slave/workspace/HBase_Nightly_master-4PMG3QPNOXT5YRQZS7HMZP3GLNX6XSF6DVHYXYIB5BWQ75VW3CPA@2/component
> # timeout=10
> Fetching upstream changes from https://git.apache.org/hbase.git
> > git --version # timeout=10
> > git fetch --no-tags --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*
> 08:50:15 ERROR: Error cloning remote repo 'origin'
> 08:50:15 hudson.plugins.git.GitException: Command "git fetch --no-tags
> --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> 08:50:15 stdout:
> 08:50:15 stderr: fatal: unable to access 'https://git.apache.org/hbase.git/':
> Failed to connect to git.apache.org port 443: Connection timed out{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21668) SCM fetch times out for nightlies
[
https://issues.apache.org/jira/browse/HBASE-21668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733191#comment-16733191
]
Sean Busbey commented on HBASE-21668:
-
I pinged INFRA. if my cell coverage holds I'll see if my login to the jenkins
nodes still works so I can confirm connectivity to the git repo
> SCM fetch times out for nightlies
> -
>
> Key: HBASE-21668
> URL: https://issues.apache.org/jira/browse/HBASE-21668
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-21668.master.001.patch
>
>
> Many of the nightly builds are failing with timeout on checkout stage with
> git fetch command. The default timeout is 2 minutes. We could either increase
> the timeout or use shallow clone that would also reduce the used space.
> Error from console output:
> {noformat}
> 08:48:10 Cloning the remote Git repository
> 08:48:10 Cloning with configured refspecs honoured and without tags
> Cloning repository https://git.apache.org/hbase.git
> > git init
> /home/jenkins/jenkins-slave/workspace/HBase_Nightly_master-4PMG3QPNOXT5YRQZS7HMZP3GLNX6XSF6DVHYXYIB5BWQ75VW3CPA@2/component
> # timeout=10
> Fetching upstream changes from https://git.apache.org/hbase.git
> > git --version # timeout=10
> > git fetch --no-tags --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*
> 08:50:15 ERROR: Error cloning remote repo 'origin'
> 08:50:15 hudson.plugins.git.GitException: Command "git fetch --no-tags
> --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> 08:50:15 stdout:
> 08:50:15 stderr: fatal: unable to access 'https://git.apache.org/hbase.git/':
> Failed to connect to git.apache.org port 443: Connection timed out{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21667) Move to latest ASF Parent POM
[ https://issues.apache.org/jira/browse/HBASE-21667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-21667: Component/s: build > Move to latest ASF Parent POM > - > > Key: HBASE-21667 > URL: https://issues.apache.org/jira/browse/HBASE-21667 > Project: HBase > Issue Type: Improvement > Components: build >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Minor > Fix For: 3.0.0, 2.2.0 > > > Currently HBase depends on version 18 which was released on 2016-05-18. > Version 21 was released in August 2018. > Relevant dependency upgrades > > ||Name||Currently used version||New version||Notes|| > |surefire.version|2.21.0|2.22.0| | > |maven-compiler-plugin|3.6.1|3.7| | > |maven-dependency-plugin|3.0.1|3.1.1| | > |maven-jar-plugin|3.0.0|3.0.2| | > |maven-javadoc-plugin|3.0.0|3.0.1| | > |maven-resources-plugin|2.7|3.1.0| | > |maven-site-plugin|3.4|3.7.1|Currently not relying on ASF version. See: > HBASE-18333| > |maven-source-plugin|3.0.0|3.0.1| | > |maven-shade-plugin|3.0.0|3.1.1|Newly added to ASF pom| > |maven-clean-plugin|3.0.0|3.1.0| | > |maven-project-info-reports-plugin |2.9|3.0.0| | > Version 21 added net.nicoulaj.maven.plugins:checksum-maven-plugin which > introduced SHA512 checksum instead of SHA1. Should verify if we can rely on > that for releases or breaks our current processes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21667) Move to latest ASF Parent POM
[ https://issues.apache.org/jira/browse/HBASE-21667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733197#comment-16733197 ] Sean Busbey commented on HBASE-21667: - no it's not required, but it is much easier when pushing to the ASF nexus repo. As you mention, we could manage that ourselves. The shade plugin change is the only one that worries me from that list. Did the minimum maven version change at all? Can we update this on branch-1 too? > Move to latest ASF Parent POM > - > > Key: HBASE-21667 > URL: https://issues.apache.org/jira/browse/HBASE-21667 > Project: HBase > Issue Type: Improvement >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Minor > Fix For: 3.0.0, 2.2.0 > > > Currently HBase depends on version 18 which was released on 2016-05-18. > Version 21 was released in August 2018. > Relevant dependency upgrades > > ||Name||Currently used version||New version||Notes|| > |surefire.version|2.21.0|2.22.0| | > |maven-compiler-plugin|3.6.1|3.7| | > |maven-dependency-plugin|3.0.1|3.1.1| | > |maven-jar-plugin|3.0.0|3.0.2| | > |maven-javadoc-plugin|3.0.0|3.0.1| | > |maven-resources-plugin|2.7|3.1.0| | > |maven-site-plugin|3.4|3.7.1|Currently not relying on ASF version. See: > HBASE-18333| > |maven-source-plugin|3.0.0|3.0.1| | > |maven-shade-plugin|3.0.0|3.1.1|Newly added to ASF pom| > |maven-clean-plugin|3.0.0|3.1.0| | > |maven-project-info-reports-plugin |2.9|3.0.0| | > Version 21 added net.nicoulaj.maven.plugins:checksum-maven-plugin which > introduced SHA512 checksum instead of SHA1. Should verify if we can rely on > that for releases or breaks our current processes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21668) SCM fetch times out for nightlies
[
https://issues.apache.org/jira/browse/HBASE-21668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733204#comment-16733204
]
Peter Somogyi commented on HBASE-21668:
---
Sure, better to check with INFRA first. From Hungary the git fetch command
takes almost 4 minutes so it could be a general slowdown on their side. Even if
it's a temporary issue I think we could improve on our nightlies by not cloning
the whole repository every time.
> SCM fetch times out for nightlies
> -
>
> Key: HBASE-21668
> URL: https://issues.apache.org/jira/browse/HBASE-21668
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-21668.master.001.patch
>
>
> Many of the nightly builds are failing with timeout on checkout stage with
> git fetch command. The default timeout is 2 minutes. We could either increase
> the timeout or use shallow clone that would also reduce the used space.
> Error from console output:
> {noformat}
> 08:48:10 Cloning the remote Git repository
> 08:48:10 Cloning with configured refspecs honoured and without tags
> Cloning repository https://git.apache.org/hbase.git
> > git init
> /home/jenkins/jenkins-slave/workspace/HBase_Nightly_master-4PMG3QPNOXT5YRQZS7HMZP3GLNX6XSF6DVHYXYIB5BWQ75VW3CPA@2/component
> # timeout=10
> Fetching upstream changes from https://git.apache.org/hbase.git
> > git --version # timeout=10
> > git fetch --no-tags --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*
> 08:50:15 ERROR: Error cloning remote repo 'origin'
> 08:50:15 hudson.plugins.git.GitException: Command "git fetch --no-tags
> --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> 08:50:15 stdout:
> 08:50:15 stderr: fatal: unable to access 'https://git.apache.org/hbase.git/':
> Failed to connect to git.apache.org port 443: Connection timed out{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21667) Move to latest ASF Parent POM
[
https://issues.apache.org/jira/browse/HBASE-21667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733212#comment-16733212
]
Peter Somogyi commented on HBASE-21667:
---
{quote}Did the minimum maven version change at all? Can we update this on
branch-1 too?
{quote}
There is a new enforcer rule for maven but it only requires version 3.0.5.
> Move to latest ASF Parent POM
> -
>
> Key: HBASE-21667
> URL: https://issues.apache.org/jira/browse/HBASE-21667
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Minor
> Fix For: 3.0.0, 2.2.0
>
>
> Currently HBase depends on version 18 which was released on 2016-05-18.
> Version 21 was released in August 2018.
> Relevant dependency upgrades
>
> ||Name||Currently used version||New version||Notes||
> |surefire.version|2.21.0|2.22.0| |
> |maven-compiler-plugin|3.6.1|3.7| |
> |maven-dependency-plugin|3.0.1|3.1.1| |
> |maven-jar-plugin|3.0.0|3.0.2| |
> |maven-javadoc-plugin|3.0.0|3.0.1| |
> |maven-resources-plugin|2.7|3.1.0| |
> |maven-site-plugin|3.4|3.7.1|Currently not relying on ASF version. See:
> HBASE-18333|
> |maven-source-plugin|3.0.0|3.0.1| |
> |maven-shade-plugin|3.0.0|3.1.1|Newly added to ASF pom|
> |maven-clean-plugin|3.0.0|3.1.0| |
> |maven-project-info-reports-plugin |2.9|3.0.0| |
> Version 21 added net.nicoulaj.maven.plugins:checksum-maven-plugin which
> introduced SHA512 checksum instead of SHA1. Should verify if we can rely on
> that for releases or breaks our current processes.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21667) Move to latest ASF Parent POM
[ https://issues.apache.org/jira/browse/HBASE-21667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733219#comment-16733219 ] stack commented on HBASE-21667: --- Nice one [~psomogyi] (finding that we've lapsed and research on what parent pom brings). +1 on upgrade. Going along w/ parent pom helps more than it hurts I think. > Move to latest ASF Parent POM > - > > Key: HBASE-21667 > URL: https://issues.apache.org/jira/browse/HBASE-21667 > Project: HBase > Issue Type: Improvement > Components: build >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Minor > Fix For: 3.0.0, 2.2.0 > > > Currently HBase depends on version 18 which was released on 2016-05-18. > Version 21 was released in August 2018. > Relevant dependency upgrades > > ||Name||Currently used version||New version||Notes|| > |surefire.version|2.21.0|2.22.0| | > |maven-compiler-plugin|3.6.1|3.7| | > |maven-dependency-plugin|3.0.1|3.1.1| | > |maven-jar-plugin|3.0.0|3.0.2| | > |maven-javadoc-plugin|3.0.0|3.0.1| | > |maven-resources-plugin|2.7|3.1.0| | > |maven-site-plugin|3.4|3.7.1|Currently not relying on ASF version. See: > HBASE-18333| > |maven-source-plugin|3.0.0|3.0.1| | > |maven-shade-plugin|3.0.0|3.1.1|Newly added to ASF pom| > |maven-clean-plugin|3.0.0|3.1.0| | > |maven-project-info-reports-plugin |2.9|3.0.0| | > Version 21 added net.nicoulaj.maven.plugins:checksum-maven-plugin which > introduced SHA512 checksum instead of SHA1. Should verify if we can rely on > that for releases or breaks our current processes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21668) SCM fetch times out for nightlies
[
https://issues.apache.org/jira/browse/HBASE-21668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733221#comment-16733221
]
stack commented on HBASE-21668:
---
+1 for shallow clone (less time to checkout and uses less space). Checking w/
INFRA seems like a good idea too to run in parallel.
> SCM fetch times out for nightlies
> -
>
> Key: HBASE-21668
> URL: https://issues.apache.org/jira/browse/HBASE-21668
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-21668.master.001.patch
>
>
> Many of the nightly builds are failing with timeout on checkout stage with
> git fetch command. The default timeout is 2 minutes. We could either increase
> the timeout or use shallow clone that would also reduce the used space.
> Error from console output:
> {noformat}
> 08:48:10 Cloning the remote Git repository
> 08:48:10 Cloning with configured refspecs honoured and without tags
> Cloning repository https://git.apache.org/hbase.git
> > git init
> /home/jenkins/jenkins-slave/workspace/HBase_Nightly_master-4PMG3QPNOXT5YRQZS7HMZP3GLNX6XSF6DVHYXYIB5BWQ75VW3CPA@2/component
> # timeout=10
> Fetching upstream changes from https://git.apache.org/hbase.git
> > git --version # timeout=10
> > git fetch --no-tags --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*
> 08:50:15 ERROR: Error cloning remote repo 'origin'
> 08:50:15 hudson.plugins.git.GitException: Command "git fetch --no-tags
> --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> 08:50:15 stdout:
> 08:50:15 stderr: fatal: unable to access 'https://git.apache.org/hbase.git/':
> Failed to connect to git.apache.org port 443: Connection timed out{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21573) More sensible client default timeout values
[ https://issues.apache.org/jira/browse/HBASE-21573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733232#comment-16733232 ] stack commented on HBASE-21573: --- This patch is really good. The doc is nice and clean. +1 . Should it be in a subissue since this thing is about changing defaults (somehow). Out of interest, do we have unit tests to ensure what we claim in the doc here? I can check. Also, would be cool if on timeout, the message pointed to this nice section in the refguide. I could go through and do this too... > More sensible client default timeout values > --- > > Key: HBASE-21573 > URL: https://issues.apache.org/jira/browse/HBASE-21573 > Project: HBase > Issue Type: Wish > Components: Client >Affects Versions: 2.1.1 >Reporter: Cosmin Lehene >Assignee: Peter Somogyi >Priority: Critical > Fix For: 2.1.3 > > Attachments: HBASE-21573.master.001.patch > > > I guess the goal is to have operations allow enough time to recover from > major failures. > While this may make sense for large jobs, it's a PITA for OLTP scenarios and > could probably benefit from a faster failure mode in default > > hbase.rpc.timeout = 6 > hbase.client.operation.timeout = 120 > hbase.client.meta.operation.timeout = 120 > The client meta ops timeout is not in defaults-xml and not documented in the > book either. > [https://hbase.apache.org/book.html#config_timeouts] > > Would it make sense to have aggressive defaults instead? > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21573) More sensible client default timeout values
[ https://issues.apache.org/jira/browse/HBASE-21573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733232#comment-16733232 ] stack edited comment on HBASE-21573 at 1/3/19 5:07 PM: --- This patch is really good. The doc is nice and clean. +1 . Should it be in a subissue since this thing is about changing defaults (somehow). Out of interest, do we have unit tests to ensure what we claim in the doc here? I can check. Also, would be cool if on timeout, the message pointed to this nice section in the refguide. I could go through and do this too... For example, though the timeout was ongoing, if exceptions pointed at the refguide, our Cosmin could have seen what he needed to change for his case where client was connecting to a dead cluster was (Author: stack): This patch is really good. The doc is nice and clean. +1 . Should it be in a subissue since this thing is about changing defaults (somehow). Out of interest, do we have unit tests to ensure what we claim in the doc here? I can check. Also, would be cool if on timeout, the message pointed to this nice section in the refguide. I could go through and do this too... > More sensible client default timeout values > --- > > Key: HBASE-21573 > URL: https://issues.apache.org/jira/browse/HBASE-21573 > Project: HBase > Issue Type: Wish > Components: Client >Affects Versions: 2.1.1 >Reporter: Cosmin Lehene >Assignee: Peter Somogyi >Priority: Critical > Fix For: 2.1.3 > > Attachments: HBASE-21573.master.001.patch > > > I guess the goal is to have operations allow enough time to recover from > major failures. > While this may make sense for large jobs, it's a PITA for OLTP scenarios and > could probably benefit from a faster failure mode in default > > hbase.rpc.timeout = 6 > hbase.client.operation.timeout = 120 > hbase.client.meta.operation.timeout = 120 > The client meta ops timeout is not in defaults-xml and not documented in the > book either. > [https://hbase.apache.org/book.html#config_timeouts] > > Would it make sense to have aggressive defaults instead? > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19327) Update the import layout for formatter
[ https://issues.apache.org/jira/browse/HBASE-19327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733260#comment-16733260 ] Chia-Ping Tsai commented on HBASE-19327: hi [~shahrs87] Welcome to hbase :) There is a formatter used to teach IDE to format hbase code. ( see https://github.com/apache/hbase/blob/master/dev-support/hbase_eclipse_formatter.xml) HBASE-19262 had changed the rule of import order so the formatter should be updated also. > Update the import layout for formatter > -- > > Key: HBASE-19327 > URL: https://issues.apache.org/jira/browse/HBASE-19327 > Project: HBase > Issue Type: Task >Reporter: Chia-Ping Tsai >Priority: Major > Labels: beginner > > HBASE-19262 changed the import order rule - the shaded* imports is in > separate group now. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21135) Build fails on windows as it fails to parse windows path during license check
[
https://issues.apache.org/jira/browse/HBASE-21135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733300#comment-16733300
]
Nihal Jain commented on HBASE-21135:
Thanks [~sreenivasulureddy].
So the windows build would fail in all branches having HBASE-16351.
> Build fails on windows as it fails to parse windows path during license check
> -
>
> Key: HBASE-21135
> URL: https://issues.apache.org/jira/browse/HBASE-21135
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0, 2.1.1
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Labels: cygwin
> Fix For: 3.0.0
>
> Attachments: HBASE-21135.master.001.patch
>
>
> License check via enforce plugin throws following error during build on
> windows:
> {code:java}
> Sourced file: inline evaluation of: ``File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-ar . . . '' Token
> Parsing Error: Lexical error at line 1, column 29. Encountered: "D" (68),
> after : "\"D:\\": {code}
> Complete stacktrace with command
> {code:java}
> mvn clean install -DskipTests -X
> {code}
> is as follows:
> {noformat}
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (check-aggregate-license) @
> hbase-shaded ---
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce from plugin
> realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1,
> parent: sun.misc.Launcher$AppClassLoader@55f96302]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce' with basic
> configurator -->
> [DEBUG] (s) fail = true
> [DEBUG] (s) failFast = false
> [DEBUG] (f) ignoreCache = false
> [DEBUG] (f) mojoExecution =
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce {execution:
> check-aggregate-license}
> [DEBUG] (s) project = MavenProject:
> org.apache.hbase:hbase-shaded:2.1.1-SNAPSHOT @
> D:\DS\HBase_2\hbase\hbase-shaded\pom.xml
> [DEBUG] (s) condition = File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] (s) message = License errors detected, for more detail find ERROR in
>
> D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE
> [DEBUG] (s) rules =
> [org.apache.maven.plugins.enforcer.EvaluateBeanshell@7e307087]
> [DEBUG] (s) session = org.apache.maven.execution.MavenSession@5e1218b4
> [DEBUG] (s) skip = false
> [DEBUG] -- end configuration --
> [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.EvaluateBeanshell
> [DEBUG] Echo condition : File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] Echo script : File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Couldn't evaluate
> condition: File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/mav
[jira] [Updated] (HBASE-21135) Build fails on windows as it fails to parse windows path during license check
[
https://issues.apache.org/jira/browse/HBASE-21135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nihal Jain updated HBASE-21135:
---
Affects Version/s: 1.4.0
1.3.2
1.1.12
1.2.7
> Build fails on windows as it fails to parse windows path during license check
> -
>
> Key: HBASE-21135
> URL: https://issues.apache.org/jira/browse/HBASE-21135
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0, 1.4.0, 1.3.2, 1.1.12, 1.2.7, 2.1.1
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Labels: cygwin
> Fix For: 3.0.0
>
> Attachments: HBASE-21135.master.001.patch
>
>
> License check via enforce plugin throws following error during build on
> windows:
> {code:java}
> Sourced file: inline evaluation of: ``File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-ar . . . '' Token
> Parsing Error: Lexical error at line 1, column 29. Encountered: "D" (68),
> after : "\"D:\\": {code}
> Complete stacktrace with command
> {code:java}
> mvn clean install -DskipTests -X
> {code}
> is as follows:
> {noformat}
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (check-aggregate-license) @
> hbase-shaded ---
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce from plugin
> realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1,
> parent: sun.misc.Launcher$AppClassLoader@55f96302]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce' with basic
> configurator -->
> [DEBUG] (s) fail = true
> [DEBUG] (s) failFast = false
> [DEBUG] (f) ignoreCache = false
> [DEBUG] (f) mojoExecution =
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce {execution:
> check-aggregate-license}
> [DEBUG] (s) project = MavenProject:
> org.apache.hbase:hbase-shaded:2.1.1-SNAPSHOT @
> D:\DS\HBase_2\hbase\hbase-shaded\pom.xml
> [DEBUG] (s) condition = File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] (s) message = License errors detected, for more detail find ERROR in
>
> D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE
> [DEBUG] (s) rules =
> [org.apache.maven.plugins.enforcer.EvaluateBeanshell@7e307087]
> [DEBUG] (s) session = org.apache.maven.execution.MavenSession@5e1218b4
> [DEBUG] (s) skip = false
> [DEBUG] -- end configuration --
> [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.EvaluateBeanshell
> [DEBUG] Echo condition : File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] Echo script : File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Couldn't evaluate
> condition: File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-
[jira] [Updated] (HBASE-21599) Fix findbugs and javadoc warnings from HBASE-21246
[
https://issues.apache.org/jira/browse/HBASE-21599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated HBASE-21599:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Pushed the v2 patch. Thanks for the review, Ankit!
> Fix findbugs and javadoc warnings from HBASE-21246
> --
>
> Key: HBASE-21599
> URL: https://issues.apache.org/jira/browse/HBASE-21599
> Project: HBase
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: HBASE-20952
>
> Attachments: HBASE-21599.HBASE-20952.001.patch,
> HBASE-21599.HBASE-20952.002.patch
>
>
> {noformat}
> [WARNING]
> /testptch/hbase/hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceManager.java:125:
> warning - Tag @link: can't find preLogRoll(Path) in
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager
> [WARNING]
> /testptch/hbase/hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceManager.java:125:
> warning - Tag @link: can't find preLogRoll(Path) in
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager
> {noformat}
> and
> {noformat}
> org.apache.hadoop.hbase.wal.DisabledWALProvider$1.equals(Object) always
> returns true{noformat}
> Pretty trivial stuff to clean up now.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21573) More sensible client default timeout values
[ https://issues.apache.org/jira/browse/HBASE-21573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733345#comment-16733345 ] Peter Somogyi commented on HBASE-21573: --- I can move this to a sub-issue or we can add the default modification to this patch if we agree on an applicable default. We have TestClientOperationTimeout and TestClientTimeouts, could be some other tests for it as well. > More sensible client default timeout values > --- > > Key: HBASE-21573 > URL: https://issues.apache.org/jira/browse/HBASE-21573 > Project: HBase > Issue Type: Wish > Components: Client >Affects Versions: 2.1.1 >Reporter: Cosmin Lehene >Assignee: Peter Somogyi >Priority: Critical > Fix For: 2.1.3 > > Attachments: HBASE-21573.master.001.patch > > > I guess the goal is to have operations allow enough time to recover from > major failures. > While this may make sense for large jobs, it's a PITA for OLTP scenarios and > could probably benefit from a faster failure mode in default > > hbase.rpc.timeout = 6 > hbase.client.operation.timeout = 120 > hbase.client.meta.operation.timeout = 120 > The client meta ops timeout is not in defaults-xml and not documented in the > book either. > [https://hbase.apache.org/book.html#config_timeouts] > > Would it make sense to have aggressive defaults instead? > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19177) Determine if custom maven-fluido-skin jar is still necessary
[ https://issues.apache.org/jira/browse/HBASE-19177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733390#comment-16733390 ] Josh Elser commented on HBASE-19177: Yeah, probably for the best. If MSKINS-137 gets picked up again and we can figure out how to make the corresponding changes to our site to use that, we can reopen this. For now, this is stalled with no one looking at it :) > Determine if custom maven-fluido-skin jar is still necessary > > > Key: HBASE-19177 > URL: https://issues.apache.org/jira/browse/HBASE-19177 > Project: HBase > Issue Type: Task > Components: website >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: 3.0.0 > > > To get a fancy, mobile-friendly website, HBASE-14785 introduced a patched > version of the maven-fluido-skin and committed the pre-built jar into our > release. > A few folks have noticed this jar lurking around the 2.0.0 alpha releases. By > version number, it doesn't seem like we'd need to have this anymore (and can > use the newest version). > Let's check it out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-19177) Determine if custom maven-fluido-skin jar is still necessary
[ https://issues.apache.org/jira/browse/HBASE-19177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved HBASE-19177. Resolution: Incomplete Fix Version/s: (was: 3.0.0) > Determine if custom maven-fluido-skin jar is still necessary > > > Key: HBASE-19177 > URL: https://issues.apache.org/jira/browse/HBASE-19177 > Project: HBase > Issue Type: Task > Components: website >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > > To get a fancy, mobile-friendly website, HBASE-14785 introduced a patched > version of the maven-fluido-skin and committed the pre-built jar into our > release. > A few folks have noticed this jar lurking around the 2.0.0 alpha releases. By > version number, it doesn't seem like we'd need to have this anymore (and can > use the newest version). > Let's check it out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21616) Port HBASE-21034 (Add new throttle type: read/write capacity unit) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-21616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733564#comment-16733564 ] Andrew Purtell commented on HBASE-21616: Change might introduce a perf issue (see HBASE-21657) so be sure to check it. > Port HBASE-21034 (Add new throttle type: read/write capacity unit) to branch-1 > -- > > Key: HBASE-21616 > URL: https://issues.apache.org/jira/browse/HBASE-21616 > Project: HBase > Issue Type: Task >Reporter: Andrew Purtell >Priority: Major > Fix For: 1.5.0 > > > Port HBASE-21034 (Add new throttle type: read/write capacity unit) to branch-1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21668) SCM fetch times out for nightlies
[
https://issues.apache.org/jira/browse/HBASE-21668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733577#comment-16733577
]
Sean Busbey commented on HBASE-21668:
-
bq. Sure, better to check with INFRA first. From Hungary the git fetch command
takes almost 4 minutes so it could be a general slowdown on their side. Even if
it's a temporary issue I think we could improve on our nightlies by not cloning
the whole repository every time.
How long does the git fetch take if you use github as the remote instead of
{{git.apache.org/hbase.git}}?
> SCM fetch times out for nightlies
> -
>
> Key: HBASE-21668
> URL: https://issues.apache.org/jira/browse/HBASE-21668
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-21668.master.001.patch
>
>
> Many of the nightly builds are failing with timeout on checkout stage with
> git fetch command. The default timeout is 2 minutes. We could either increase
> the timeout or use shallow clone that would also reduce the used space.
> Error from console output:
> {noformat}
> 08:48:10 Cloning the remote Git repository
> 08:48:10 Cloning with configured refspecs honoured and without tags
> Cloning repository https://git.apache.org/hbase.git
> > git init
> /home/jenkins/jenkins-slave/workspace/HBase_Nightly_master-4PMG3QPNOXT5YRQZS7HMZP3GLNX6XSF6DVHYXYIB5BWQ75VW3CPA@2/component
> # timeout=10
> Fetching upstream changes from https://git.apache.org/hbase.git
> > git --version # timeout=10
> > git fetch --no-tags --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*
> 08:50:15 ERROR: Error cloning remote repo 'origin'
> 08:50:15 hudson.plugins.git.GitException: Command "git fetch --no-tags
> --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> 08:50:15 stdout:
> 08:50:15 stderr: fatal: unable to access 'https://git.apache.org/hbase.git/':
> Failed to connect to git.apache.org port 443: Connection timed out{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21668) SCM fetch times out for nightlies
[
https://issues.apache.org/jira/browse/HBASE-21668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733579#comment-16733579
]
Sean Busbey commented on HBASE-21668:
-
I think the version of Yetus we use might do a full fetch even if we do a
shallow clone in the first place, so I'm not sure how much we'll save in
overall time by putting it off.
> SCM fetch times out for nightlies
> -
>
> Key: HBASE-21668
> URL: https://issues.apache.org/jira/browse/HBASE-21668
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-21668.master.001.patch
>
>
> Many of the nightly builds are failing with timeout on checkout stage with
> git fetch command. The default timeout is 2 minutes. We could either increase
> the timeout or use shallow clone that would also reduce the used space.
> Error from console output:
> {noformat}
> 08:48:10 Cloning the remote Git repository
> 08:48:10 Cloning with configured refspecs honoured and without tags
> Cloning repository https://git.apache.org/hbase.git
> > git init
> /home/jenkins/jenkins-slave/workspace/HBase_Nightly_master-4PMG3QPNOXT5YRQZS7HMZP3GLNX6XSF6DVHYXYIB5BWQ75VW3CPA@2/component
> # timeout=10
> Fetching upstream changes from https://git.apache.org/hbase.git
> > git --version # timeout=10
> > git fetch --no-tags --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*
> 08:50:15 ERROR: Error cloning remote repo 'origin'
> 08:50:15 hudson.plugins.git.GitException: Command "git fetch --no-tags
> --progress https://git.apache.org/hbase.git
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> 08:50:15 stdout:
> 08:50:15 stderr: fatal: unable to access 'https://git.apache.org/hbase.git/':
> Failed to connect to git.apache.org port 443: Connection timed out{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21476) Support for nanosecond timestamps
[ https://issues.apache.org/jira/browse/HBASE-21476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Elenskiy updated HBASE-21476: Attachment: HBASE-21476.branch-2.1.0003.patch > Support for nanosecond timestamps > - > > Key: HBASE-21476 > URL: https://issues.apache.org/jira/browse/HBASE-21476 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.1.1 >Reporter: Andrey Elenskiy >Assignee: Andrey Elenskiy >Priority: Major > Labels: features, patch > Attachments: Apache HBase - Nanosecond Timestamps v1.pdf, > HBASE-21476.branch-2.1.0003.patch, nanosecond_timestamps_v1.patch, > nanosecond_timestamps_v2.patch > > > Introducing a new table attribute "NANOSECOND_TIMESTAMPS" to tell HBase to > handle timestamps with nanosecond precision. This is useful for applications > that timestamp updates at the source with nanoseconds and still want features > like column family TTL and "hbase.hstore.time.to.purge.deletes" to work. > The attribute should be specified either on new tables or on existing tables > which have timestamps only with nanosecond precision. There's no migration > from milliseconds to nanoseconds for already existing tables. We could add > this migration as part of compaction if you think that would be useful, but > that would obviously make the change more complex. > I've added a new EnvironmentEdge method "currentTimeNano()" that uses > [java.time.Instant|https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html] > to get time in nanoseconds which means it will only work with Java 8. The > idea is to gradually replace all places where "EnvironmentEdge.currentTime()" > is used to have HBase working purely with nanoseconds (which is a > prerequisite for HBASE-14070). Also, I've refactored ScanInfo and > PartitionedMobCompactor to expect TableDescriptor as an argument which makes > code a little cleaner and easier to extend. > Couple more points: > - column family TTL (specified in seconds) and > "hbase.hstore.time.to.purge.deletes" (specified in milliseconds) options > don't need to be changed, those are adjusted automatically. > - Per cell TTL needs to be scaled by clients accordingly after > "NANOSECOND_TIMESTAMPS" table attribute is specified. > Looking for everyone's feedback to know if that's a worthwhile direction. > Will add more comprehensive tests in a later patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21476) Support for nanosecond timestamps
[ https://issues.apache.org/jira/browse/HBASE-21476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733655#comment-16733655 ] Andrey Elenskiy commented on HBASE-21476: - Added "-Dhbase.tests.nanosecond.timestamps" to run the existing tests that are using HBaseTestingUtility with NANOSECOND_TIMESTAMPS table attribute. Would be great if someone could trigger the build with this flag since some tests (TestClientClusterMetrics and TestNettyIPC) timeout on my machine preventing from running other tests. As for bulk imports, I don't quite know what could be updated as it's the same problem: it's up to the client to be aware what they are importing into what version of a table. It's the client that specifies the timestamps. > Support for nanosecond timestamps > - > > Key: HBASE-21476 > URL: https://issues.apache.org/jira/browse/HBASE-21476 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.1.1 >Reporter: Andrey Elenskiy >Assignee: Andrey Elenskiy >Priority: Major > Labels: features, patch > Attachments: Apache HBase - Nanosecond Timestamps v1.pdf, > HBASE-21476.branch-2.1.0003.patch, nanosecond_timestamps_v1.patch, > nanosecond_timestamps_v2.patch > > > Introducing a new table attribute "NANOSECOND_TIMESTAMPS" to tell HBase to > handle timestamps with nanosecond precision. This is useful for applications > that timestamp updates at the source with nanoseconds and still want features > like column family TTL and "hbase.hstore.time.to.purge.deletes" to work. > The attribute should be specified either on new tables or on existing tables > which have timestamps only with nanosecond precision. There's no migration > from milliseconds to nanoseconds for already existing tables. We could add > this migration as part of compaction if you think that would be useful, but > that would obviously make the change more complex. > I've added a new EnvironmentEdge method "currentTimeNano()" that uses > [java.time.Instant|https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html] > to get time in nanoseconds which means it will only work with Java 8. The > idea is to gradually replace all places where "EnvironmentEdge.currentTime()" > is used to have HBase working purely with nanoseconds (which is a > prerequisite for HBASE-14070). Also, I've refactored ScanInfo and > PartitionedMobCompactor to expect TableDescriptor as an argument which makes > code a little cleaner and easier to extend. > Couple more points: > - column family TTL (specified in seconds) and > "hbase.hstore.time.to.purge.deletes" (specified in milliseconds) options > don't need to be changed, those are adjusted automatically. > - Per cell TTL needs to be scaled by clients accordingly after > "NANOSECOND_TIMESTAMPS" table attribute is specified. > Looking for everyone's feedback to know if that's a worthwhile direction. > Will add more comprehensive tests in a later patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21456) Make WALFactory only used for creating WALProviders
[ https://issues.apache.org/jira/browse/HBASE-21456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated HBASE-21456: -- Attachment: HBASE-21456.HBASE-20952.wip.patch > Make WALFactory only used for creating WALProviders > --- > > Key: HBASE-21456 > URL: https://issues.apache.org/jira/browse/HBASE-21456 > Project: HBase > Issue Type: Sub-task > Components: wal >Reporter: Josh Elser >Priority: Major > Attachments: HBASE-21456.HBASE-20952.wip.patch > > > As a Factory, WALFactory should only have one job: creating instances of > WALProvider. > However, over the years, it has been a landing place for lots of wal-related > methods (e.g. constructing readers, WALEntryStream, and more). We want all of > this to live in the WALProvider. > We can do this in two steps: have the WALFactory methods invoke the method on > the WALProvider (handled elsewhere), then here we can replace usage of the > WALFactory "wrapper methods" with the WALProvider itself. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HBASE-21456) Make WALFactory only used for creating WALProviders
[ https://issues.apache.org/jira/browse/HBASE-21456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal reassigned HBASE-21456: - Assignee: Ankit Singhal > Make WALFactory only used for creating WALProviders > --- > > Key: HBASE-21456 > URL: https://issues.apache.org/jira/browse/HBASE-21456 > Project: HBase > Issue Type: Sub-task > Components: wal >Reporter: Josh Elser >Assignee: Ankit Singhal >Priority: Major > Attachments: HBASE-21456.HBASE-20952.wip.patch > > > As a Factory, WALFactory should only have one job: creating instances of > WALProvider. > However, over the years, it has been a landing place for lots of wal-related > methods (e.g. constructing readers, WALEntryStream, and more). We want all of > this to live in the WALProvider. > We can do this in two steps: have the WALFactory methods invoke the method on > the WALProvider (handled elsewhere), then here we can replace usage of the > WALFactory "wrapper methods" with the WALProvider itself. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (HBASE-21456) Make WALFactory only used for creating WALProviders
[ https://issues.apache.org/jira/browse/HBASE-21456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-21456 started by Ankit Singhal. - > Make WALFactory only used for creating WALProviders > --- > > Key: HBASE-21456 > URL: https://issues.apache.org/jira/browse/HBASE-21456 > Project: HBase > Issue Type: Sub-task > Components: wal >Reporter: Josh Elser >Assignee: Ankit Singhal >Priority: Major > Attachments: HBASE-21456.HBASE-20952.wip.patch > > > As a Factory, WALFactory should only have one job: creating instances of > WALProvider. > However, over the years, it has been a landing place for lots of wal-related > methods (e.g. constructing readers, WALEntryStream, and more). We want all of > this to live in the WALProvider. > We can do this in two steps: have the WALFactory methods invoke the method on > the WALProvider (handled elsewhere), then here we can replace usage of the > WALFactory "wrapper methods" with the WALProvider itself. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21456) Make WALFactory only used for creating WALProviders
[ https://issues.apache.org/jira/browse/HBASE-21456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733680#comment-16733680 ] Ankit Singhal commented on HBASE-21456: --- Uploading wip patch, as there are some test failures which needs to be taken care and better handling of delegate WAL providers. > Make WALFactory only used for creating WALProviders > --- > > Key: HBASE-21456 > URL: https://issues.apache.org/jira/browse/HBASE-21456 > Project: HBase > Issue Type: Sub-task > Components: wal >Reporter: Josh Elser >Assignee: Ankit Singhal >Priority: Major > Attachments: HBASE-21456.HBASE-20952.wip.patch > > > As a Factory, WALFactory should only have one job: creating instances of > WALProvider. > However, over the years, it has been a landing place for lots of wal-related > methods (e.g. constructing readers, WALEntryStream, and more). We want all of > this to live in the WALProvider. > We can do this in two steps: have the WALFactory methods invoke the method on > the WALProvider (handled elsewhere), then here we can replace usage of the > WALFactory "wrapper methods" with the WALProvider itself. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21588) Procedure v2 wal splitting implementation
[ https://issues.apache.org/jira/browse/HBASE-21588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-21588: - Attachment: HBASE-21588.master.019.patch > Procedure v2 wal splitting implementation > - > > Key: HBASE-21588 > URL: https://issues.apache.org/jira/browse/HBASE-21588 > Project: HBase > Issue Type: Sub-task >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Attachments: HBASE-21588.master.003.patch, > HBASE-21588.master.004.patch, HBASE-21588.master.005.patch, > HBASE-21588.master.006.patch, HBASE-21588.master.007.patch, > HBASE-21588.master.008.patch, HBASE-21588.master.009.patch, > HBASE-21588.master.010.patch, HBASE-21588.master.011.patch, > HBASE-21588.master.012.patch, HBASE-21588.master.013.patch, > HBASE-21588.master.014.patch, HBASE-21588.master.015.patch, > HBASE-21588.master.016.patch, HBASE-21588.master.017.patch, > HBASE-21588.master.018.patch, HBASE-21588.master.018.patch, > HBASE-21588.master.019.patch > > > create a sub task to submit the implementation of procedure v2 wal splitting -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21588) Procedure v2 wal splitting implementation
[ https://issues.apache.org/jira/browse/HBASE-21588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733745#comment-16733745 ] Jingyun Tian commented on HBASE-21588: -- There are some problems with my UT. I fixed it and successfully runs 20 times in straight. > Procedure v2 wal splitting implementation > - > > Key: HBASE-21588 > URL: https://issues.apache.org/jira/browse/HBASE-21588 > Project: HBase > Issue Type: Sub-task >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Attachments: HBASE-21588.master.003.patch, > HBASE-21588.master.004.patch, HBASE-21588.master.005.patch, > HBASE-21588.master.006.patch, HBASE-21588.master.007.patch, > HBASE-21588.master.008.patch, HBASE-21588.master.009.patch, > HBASE-21588.master.010.patch, HBASE-21588.master.011.patch, > HBASE-21588.master.012.patch, HBASE-21588.master.013.patch, > HBASE-21588.master.014.patch, HBASE-21588.master.015.patch, > HBASE-21588.master.016.patch, HBASE-21588.master.017.patch, > HBASE-21588.master.018.patch, HBASE-21588.master.018.patch, > HBASE-21588.master.019.patch > > > create a sub task to submit the implementation of procedure v2 wal splitting -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21657) PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% scan case.
[
https://issues.apache.org/jira/browse/HBASE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733059#comment-16733059
]
Zheng Hu edited comment on HBASE-21657 at 1/4/19 3:31 AM:
--
I made an performance comparasion between hbase2.0.4 without patch.v2 and
hbase2.0.4 with patch.v2:
||Comparision||QPS|FlameGraph|L2 cacheHitRatio|
|HBase2.0.4 without patch.v2|9979.8
ops/sec|[^hbase2.0.4-ssd-scan-traces.svg]|~95%|
|HBase2.0.4 with patch.v2|14392.7
ops/sec|[^hbase2.0.4-ssd-scan-traces.2.svg]|~95%|
Later, I'll provide more details about the QPS & latency.
BTW, my testing environment were:
5 Nodes : 12*800G SSD / 24 Core / 128GB memory (50G onheap + 50G offheap for
each RS, and allocated 36G for BucketCache).
and I used the YCSB 100% scan workload (by default, the ycsb will generate a
scan with limit in [1...1000] )
{code:java}
table=ycsb-test
columnfamily=C
recordcount=1
operationcount=1
workload=com.yahoo.ycsb.workloads.CoreWorkload
fieldlength=100
fieldcount=1
clientbuffering=true
readallfields=true
writeallfields=true
readproportion=0
updateproportion=0
scanproportion=1.0
insertproportion=0
requestdistribution=zipfian
{code}
was (Author: openinx):
I made an performance comparasion between hbase2.0.4 without patch.v2 and
hbase2.0.4 with patch.v2:
|| Comparision || QPS| FlameGraph| L2 cacheHitRatio|
|HBase2.0.4 without patch.v2|14392.7 ops/sec| [^hbase2.0.4-ssd-scan-traces.svg]
| ~95%|
|HBase2.0.4 with patch.v2| 9979.8 ops/sec| [^hbase2.0.4-ssd-scan-traces.2.svg]
| ~95% |
Later, I'll provide more details about the QPS & latency.
BTW, my testing environment were:
5 Nodes : 12*800G SSD / 24 Core / 128GB memory (50G onheap + 50G offheap for
each RS, and allocated 36G for BucketCache).
and I used the YCSB 100% scan workload (by default, the ycsb will generate a
scan with limit in [1...1000] )
{code}
table=ycsb-test
columnfamily=C
recordcount=1
operationcount=1
workload=com.yahoo.ycsb.workloads.CoreWorkload
fieldlength=100
fieldcount=1
clientbuffering=true
readallfields=true
writeallfields=true
readproportion=0
updateproportion=0
scanproportion=1.0
insertproportion=0
requestdistribution=zipfian
{code}
> PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100%
> scan case.
>
>
> Key: HBASE-21657
> URL: https://issues.apache.org/jira/browse/HBASE-21657
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21657.v1.patch, HBASE-21657.v2.patch,
> hbase2.0.4-ssd-scan-traces.2.svg, hbase2.0.4-ssd-scan-traces.svg,
> hbase20-ssd-100-scan-traces.svg
>
>
> We are evaluating the performance of branch-2, and find that the throughput
> of scan in SSD cluster is almost the same as HDD cluster. so I made a
> FlameGraph on RS, and found that the
> PrivateCellUtil#estimatedSerializedSizeOf cost about 29% cpu, Obviously, it
> has been the bottleneck in 100% scan case.
> See the [^hbase20-ssd-100-scan-traces.svg]
> BTW, in our XiaoMi branch, we introduce a
> HRegion#updateReadRequestsByCapacityUnitPerSecond to sum up the size of cells
> (for metric monitor), so it seems the performance loss was amplified.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21476) Support for nanosecond timestamps
[
https://issues.apache.org/jira/browse/HBASE-21476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733812#comment-16733812
]
Hadoop QA commented on HBASE-21476:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
10s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} 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 12 new or modified test
files. {color} |
|| || || || {color:brown} branch-2.1 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
5s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
5s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
32s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
34s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
10s{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
9s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
23s{color} | {color:green} branch-2.1 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
24s{color} | {color:green} hbase-common: The patch generated 0 new + 0
unchanged - 1 fixed = 0 total (was 1) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
33s{color} | {color:green} hbase-client: The patch generated 0 new + 69
unchanged - 5 fixed = 69 total (was 74) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
22s{color} | {color:red} hbase-server: The patch generated 18 new + 841
unchanged - 8 fixed = 859 total (was 849) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s{color} | {color:green} The patch passed checkstyle in hbase-shell {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
6s{color} | {color:red} The patch generated 2 new + 0 unchanged - 411 fixed = 2
total (was 411) {color} |
| {color:orange}-0{color} | {color:orange} ruby-lint {color} | {color:orange}
0m 2s{color} | {color:orange} The patch generated 1 new + 596 unchanged - 151
fixed = 597 total (was 747) {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
5s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 30s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
47s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
32s{color} | {color:red} hbase-server generated 2 new + 1 unchanged - 0 fixed =
3 total (was 1) {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
41s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
10s{color} | {color:green} hbase-client in the patch passed. {color} |
|
[jira] [Created] (HBASE-21669) Move branch-2.0 to 2.0.5-SNAPSHOT version after release of 2.0.4
stack created HBASE-21669:
-
Summary: Move branch-2.0 to 2.0.5-SNAPSHOT version after release
of 2.0.4
Key: HBASE-21669
URL: https://issues.apache.org/jira/browse/HBASE-21669
Project: HBase
Issue Type: Sub-task
Reporter: stack
$ mvn clean org.codehaus.mojo:versions-maven-plugin:2.5:set
-DnewVersion=2.0.5-SNAPSHOT
$ find . -name pom.xml -exec git add {} \;
$ git commit ...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HBASE-21669) Move branch-2.0 to 2.0.5-SNAPSHOT version after release of 2.0.4
[
https://issues.apache.org/jira/browse/HBASE-21669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-21669.
---
Resolution: Fixed
Assignee: stack
Fix Version/s: 2.0.5
Pushed on branch-2.0.
> Move branch-2.0 to 2.0.5-SNAPSHOT version after release of 2.0.4
>
>
> Key: HBASE-21669
> URL: https://issues.apache.org/jira/browse/HBASE-21669
> Project: HBase
> Issue Type: Sub-task
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 2.0.5
>
>
> $ mvn clean org.codehaus.mojo:versions-maven-plugin:2.5:set
> -DnewVersion=2.0.5-SNAPSHOT
> $ find . -name pom.xml -exec git add {} \;
> $ git commit ...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21670) Add 2.0.4 to download page
stack created HBASE-21670: - Summary: Add 2.0.4 to download page Key: HBASE-21670 URL: https://issues.apache.org/jira/browse/HBASE-21670 Project: HBase Issue Type: Sub-task Reporter: stack Update the download page on site to have 2.0.4 instead of 2.0.3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21657) PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% scan case.
[ https://issues.apache.org/jira/browse/HBASE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-21657: - Attachment: HBase2.0.4-without-patch-v2.png HBase2.0.4-with-patch.v2.png > PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% > scan case. > > > Key: HBASE-21657 > URL: https://issues.apache.org/jira/browse/HBASE-21657 > Project: HBase > Issue Type: Bug > Components: Performance >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21657.v1.patch, HBASE-21657.v2.patch, > HBase2.0.4-with-patch.v2.png, HBase2.0.4-without-patch-v2.png, > hbase2.0.4-ssd-scan-traces.2.svg, hbase2.0.4-ssd-scan-traces.svg, > hbase20-ssd-100-scan-traces.svg > > > We are evaluating the performance of branch-2, and find that the throughput > of scan in SSD cluster is almost the same as HDD cluster. so I made a > FlameGraph on RS, and found that the > PrivateCellUtil#estimatedSerializedSizeOf cost about 29% cpu, Obviously, it > has been the bottleneck in 100% scan case. > See the [^hbase20-ssd-100-scan-traces.svg] > BTW, in our XiaoMi branch, we introduce a > HRegion#updateReadRequestsByCapacityUnitPerSecond to sum up the size of cells > (for metric monitor), so it seems the performance loss was amplified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21657) PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% scan case.
[
https://issues.apache.org/jira/browse/HBASE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733059#comment-16733059
]
Zheng Hu edited comment on HBASE-21657 at 1/4/19 5:33 AM:
--
I made an performance comparasion between hbase2.0.4 without patch.v2 and
hbase2.0.4 with patch.v2:
||Comparision||QPS||FlameGraph||L2 cacheHitRatio||Latency||
|HBase2.0.4 without patch.v2|9979.8
ops/sec|[^hbase2.0.4-ssd-scan-traces.svg]|~95%|
[Graph.1|https://issues.apache.org/jira/secure/attachment/12953712/HBase2.0.4-without-patch-v2.png]
|
|HBase2.0.4 with patch.v2|14392.7
ops/sec|[^hbase2.0.4-ssd-scan-traces.2.svg]|~95%|
[Graph.2|https://issues.apache.org/jira/secure/attachment/12953711/HBase2.0.4-with-patch.v2.png]
|
Later, I'll provide more details about the QPS & latency.
BTW, my testing environment were:
5 Nodes : 12*800G SSD / 24 Core / 128GB memory (50G onheap + 50G offheap for
each RS, and allocated 36G for BucketCache).
and I used the YCSB 100% scan workload (by default, the ycsb will generate a
scan with limit in [1...1000] )
{code:java}
table=ycsb-test
columnfamily=C
recordcount=1
operationcount=1
workload=com.yahoo.ycsb.workloads.CoreWorkload
fieldlength=100
fieldcount=1
clientbuffering=true
readallfields=true
writeallfields=true
readproportion=0
updateproportion=0
scanproportion=1.0
insertproportion=0
requestdistribution=zipfian
{code}
was (Author: openinx):
I made an performance comparasion between hbase2.0.4 without patch.v2 and
hbase2.0.4 with patch.v2:
||Comparision||QPS|FlameGraph|L2 cacheHitRatio|
|HBase2.0.4 without patch.v2|9979.8
ops/sec|[^hbase2.0.4-ssd-scan-traces.svg]|~95%|
|HBase2.0.4 with patch.v2|14392.7
ops/sec|[^hbase2.0.4-ssd-scan-traces.2.svg]|~95%|
Later, I'll provide more details about the QPS & latency.
BTW, my testing environment were:
5 Nodes : 12*800G SSD / 24 Core / 128GB memory (50G onheap + 50G offheap for
each RS, and allocated 36G for BucketCache).
and I used the YCSB 100% scan workload (by default, the ycsb will generate a
scan with limit in [1...1000] )
{code:java}
table=ycsb-test
columnfamily=C
recordcount=1
operationcount=1
workload=com.yahoo.ycsb.workloads.CoreWorkload
fieldlength=100
fieldcount=1
clientbuffering=true
readallfields=true
writeallfields=true
readproportion=0
updateproportion=0
scanproportion=1.0
insertproportion=0
requestdistribution=zipfian
{code}
> PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100%
> scan case.
>
>
> Key: HBASE-21657
> URL: https://issues.apache.org/jira/browse/HBASE-21657
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21657.v1.patch, HBASE-21657.v2.patch,
> HBase2.0.4-with-patch.v2.png, HBase2.0.4-without-patch-v2.png,
> hbase2.0.4-ssd-scan-traces.2.svg, hbase2.0.4-ssd-scan-traces.svg,
> hbase20-ssd-100-scan-traces.svg
>
>
> We are evaluating the performance of branch-2, and find that the throughput
> of scan in SSD cluster is almost the same as HDD cluster. so I made a
> FlameGraph on RS, and found that the
> PrivateCellUtil#estimatedSerializedSizeOf cost about 29% cpu, Obviously, it
> has been the bottleneck in 100% scan case.
> See the [^hbase20-ssd-100-scan-traces.svg]
> BTW, in our XiaoMi branch, we introduce a
> HRegion#updateReadRequestsByCapacityUnitPerSecond to sum up the size of cells
> (for metric monitor), so it seems the performance loss was amplified.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HBASE-21670) Add 2.0.4 to download page
[ https://issues.apache.org/jira/browse/HBASE-21670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-21670. --- Resolution: Fixed Assignee: stack Fix Version/s: 2.0.4 Edited downloads page and pushed to master branch. > Add 2.0.4 to download page > -- > > Key: HBASE-21670 > URL: https://issues.apache.org/jira/browse/HBASE-21670 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.4 > > > Update the download page on site to have 2.0.4 instead of 2.0.3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21657) PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% scan case.
[
https://issues.apache.org/jira/browse/HBASE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733059#comment-16733059
]
Zheng Hu edited comment on HBASE-21657 at 1/4/19 5:36 AM:
--
I made an performance comparasion between hbase2.0.4 without patch.v2 and
hbase2.0.4 with patch.v2:
||Comparision||QPS||FlameGraph||L2 cacheHitRatio||Latency||
|HBase2.0.4 without patch.v2|9979.8
ops/sec|[^hbase2.0.4-ssd-scan-traces.svg]|~95%|[^HBase2.0.4-without-patch-v2.png]|
|HBase2.0.4 with patch.v2|14392.7
ops/sec|[^hbase2.0.4-ssd-scan-traces.2.svg]|~95%|[^HBase2.0.4-with-patch.v2.png]|
So , we can see there's big diff between those two case. After appling
patch.v2, we got about ~ 40% throughtput improvement.
BTW, my testing environment were:
5 Nodes : 12*800G SSD / 24 Core / 128GB memory (50G onheap + 50G offheap for
each RS, and allocated 36G for BucketCache).
and I used the YCSB 100% scan workload (by default, the ycsb will generate a
scan with limit in [1...1000] )
{code:java}
table=ycsb-test
columnfamily=C
recordcount=1
operationcount=1
workload=com.yahoo.ycsb.workloads.CoreWorkload
fieldlength=100
fieldcount=1
clientbuffering=true
readallfields=true
writeallfields=true
readproportion=0
updateproportion=0
scanproportion=1.0
insertproportion=0
requestdistribution=zipfian
{code}
was (Author: openinx):
I made an performance comparasion between hbase2.0.4 without patch.v2 and
hbase2.0.4 with patch.v2:
||Comparision||QPS||FlameGraph||L2 cacheHitRatio||Latency||
|HBase2.0.4 without patch.v2|9979.8
ops/sec|[^hbase2.0.4-ssd-scan-traces.svg]|~95%|
[Graph.1|https://issues.apache.org/jira/secure/attachment/12953712/HBase2.0.4-without-patch-v2.png]
|
|HBase2.0.4 with patch.v2|14392.7
ops/sec|[^hbase2.0.4-ssd-scan-traces.2.svg]|~95%|
[Graph.2|https://issues.apache.org/jira/secure/attachment/12953711/HBase2.0.4-with-patch.v2.png]
|
Later, I'll provide more details about the QPS & latency.
BTW, my testing environment were:
5 Nodes : 12*800G SSD / 24 Core / 128GB memory (50G onheap + 50G offheap for
each RS, and allocated 36G for BucketCache).
and I used the YCSB 100% scan workload (by default, the ycsb will generate a
scan with limit in [1...1000] )
{code:java}
table=ycsb-test
columnfamily=C
recordcount=1
operationcount=1
workload=com.yahoo.ycsb.workloads.CoreWorkload
fieldlength=100
fieldcount=1
clientbuffering=true
readallfields=true
writeallfields=true
readproportion=0
updateproportion=0
scanproportion=1.0
insertproportion=0
requestdistribution=zipfian
{code}
> PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100%
> scan case.
>
>
> Key: HBASE-21657
> URL: https://issues.apache.org/jira/browse/HBASE-21657
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21657.v1.patch, HBASE-21657.v2.patch,
> HBase2.0.4-with-patch.v2.png, HBase2.0.4-without-patch-v2.png,
> hbase2.0.4-ssd-scan-traces.2.svg, hbase2.0.4-ssd-scan-traces.svg,
> hbase20-ssd-100-scan-traces.svg
>
>
> We are evaluating the performance of branch-2, and find that the throughput
> of scan in SSD cluster is almost the same as HDD cluster. so I made a
> FlameGraph on RS, and found that the
> PrivateCellUtil#estimatedSerializedSizeOf cost about 29% cpu, Obviously, it
> has been the bottleneck in 100% scan case.
> See the [^hbase20-ssd-100-scan-traces.svg]
> BTW, in our XiaoMi branch, we introduce a
> HRegion#updateReadRequestsByCapacityUnitPerSecond to sum up the size of cells
> (for metric monitor), so it seems the performance loss was amplified.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21630) [shell] Define ENDKEY == STOPROW (we have ENDROW)
[ https://issues.apache.org/jira/browse/HBASE-21630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-21630: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.0.5 2.1.3 2.2.0 3.0.0 Status: Resolved (was: Patch Available) +1 on the patch [~nihaljain.cs] I fixed the rubocop complaints on commit. Pushed to branch-2.0+. > [shell] Define ENDKEY == STOPROW (we have ENDROW) > - > > Key: HBASE-21630 > URL: https://issues.apache.org/jira/browse/HBASE-21630 > Project: HBase > Issue Type: Bug > Components: shell >Reporter: stack >Assignee: Nihal Jain >Priority: Trivial > Labels: beginner > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-20630.master.001.patch > > > Small fix... In HTableDescriptor, the end row is labelled ENDKEY. In the > shell, I should be able to scan to the ENDKEY... but I can't. Scan takes > STOPROW or ENDROW. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21555) Create 2.0.4 release
[ https://issues.apache.org/jira/browse/HBASE-21555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733845#comment-16733845 ] stack commented on HBASE-21555: --- RC1 passed. * Closed the vote. * Tagged 205e39c5704bf38568b34926dde9f1ee76e6b5d0 as rel/2.0.4 and pushed tag upstream. * Released the maven repo staged artifact. * Moved the version on to 2.0.5-SNAPSHOT as subtask. * Remove release/hbase/2.0.3 * svn mv dev/hbase/hbase-2.0.4RC1 release/hbase/2.0.4 under URL: https://dist.apache.org/repos/dist * svn commit. * Update the download page (see subtask). * Release 2.0.4 in JIRA. Waiting till morning to send announcement while artifacts propagate and until show on download page. > Create 2.0.4 release > > > Key: HBASE-21555 > URL: https://issues.apache.org/jira/browse/HBASE-21555 > Project: HBase > Issue Type: Task >Reporter: stack >Assignee: stack >Priority: Major > Attachments: Screen Shot 2018-12-05 at 8.38.32 PM.png > > > Roll new 2.1 because of memory leak. See HBASE-21551 > Branch-2.0 was doing nicely. 10 of the last 14 passed here is a run of 6 > back-to-back that all passed. !Screen Shot 2018-12-05 at 8.38.32 PM.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21657) PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% scan case.
[ https://issues.apache.org/jira/browse/HBASE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733856#comment-16733856 ] stack commented on HBASE-21657: --- Thanks for turning up this one. Whats the hdd flamegraph look like? It was same version? Where is it spending time? In same place? bq. The complicated condition sentences which may lead to the JVM inline did not work Which are these [~openinx] ? And when you say, did not work, is it that they are not inlining? (That StoreScanner#next is a massive method. It for sure does not inline so anything under it such as estimated size will not inline either). Whats the flamegraph look like now? Why you think the speedup? Adding serialized size to Cell Interface is a radical change but having defaults makes it easier and hard to argue w/ a 40% speedup (do we have to have two methods... one with tags and one without? Can't the Cell figure if it has tags or not?). > PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% > scan case. > > > Key: HBASE-21657 > URL: https://issues.apache.org/jira/browse/HBASE-21657 > Project: HBase > Issue Type: Bug > Components: Performance >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21657.v1.patch, HBASE-21657.v2.patch, > HBase2.0.4-with-patch.v2.png, HBase2.0.4-without-patch-v2.png, > hbase2.0.4-ssd-scan-traces.2.svg, hbase2.0.4-ssd-scan-traces.svg, > hbase20-ssd-100-scan-traces.svg > > > We are evaluating the performance of branch-2, and find that the throughput > of scan in SSD cluster is almost the same as HDD cluster. so I made a > FlameGraph on RS, and found that the > PrivateCellUtil#estimatedSerializedSizeOf cost about 29% cpu, Obviously, it > has been the bottleneck in 100% scan case. > See the [^hbase20-ssd-100-scan-traces.svg] > BTW, in our XiaoMi branch, we introduce a > HRegion#updateReadRequestsByCapacityUnitPerSecond to sum up the size of cells > (for metric monitor), so it seems the performance loss was amplified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21657) PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% scan case.
[ https://issues.apache.org/jira/browse/HBASE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733858#comment-16733858 ] stack commented on HBASE-21657: --- Oh, just to say I had similar travails over in HBASE-20188 [TESTING] Performance trying to get the CPU to have a better profile random reading. Didn't get to Scans. In HBASE-20188, messing w/ inlining, caching calculations, and earlier selection on whether extendedcell or not paid dividends. The StoreScanner#next here is nasty. Could you get a flame graph from your current prod to see what its flamegraph looks like -- where branch-1 is spending its time Scanning? Thanks [~openinx]. > PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100% > scan case. > > > Key: HBASE-21657 > URL: https://issues.apache.org/jira/browse/HBASE-21657 > Project: HBase > Issue Type: Bug > Components: Performance >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21657.v1.patch, HBASE-21657.v2.patch, > HBase2.0.4-with-patch.v2.png, HBase2.0.4-without-patch-v2.png, > hbase2.0.4-ssd-scan-traces.2.svg, hbase2.0.4-ssd-scan-traces.svg, > hbase20-ssd-100-scan-traces.svg > > > We are evaluating the performance of branch-2, and find that the throughput > of scan in SSD cluster is almost the same as HDD cluster. so I made a > FlameGraph on RS, and found that the > PrivateCellUtil#estimatedSerializedSizeOf cost about 29% cpu, Obviously, it > has been the bottleneck in 100% scan case. > See the [^hbase20-ssd-100-scan-traces.svg] > BTW, in our XiaoMi branch, we introduce a > HRegion#updateReadRequestsByCapacityUnitPerSecond to sum up the size of cells > (for metric monitor), so it seems the performance loss was amplified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21159) Add shell command to switch throttle on or off
[ https://issues.apache.org/jira/browse/HBASE-21159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Mei updated HBASE-21159: --- Attachment: HBASE-21159.master.008.patch > Add shell command to switch throttle on or off > -- > > Key: HBASE-21159 > URL: https://issues.apache.org/jira/browse/HBASE-21159 > Project: HBase > Issue Type: Sub-task >Affects Versions: 3.0.0, 2.2.0 >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > Attachments: HBASE-21159.master.001.patch, > HBASE-21159.master.002.patch, HBASE-21159.master.003.patch, > HBASE-21159.master.004.patch, HBASE-21159.master.005.patch, > HBASE-21159.master.006.patch, HBASE-21159.master.007.patch, > HBASE-21159.master.008.patch > > > Add shell command to switch throttle on or off. When throttle is off, HBase > will not throttle any request. This feature may be useful in production > environment. > We can use the following commands to switch throttle: > throttle_switch true / throttle_switch false -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21538) Rewrite RegionReplicaFlushHandler to use AsyncClusterConnection
[ https://issues.apache.org/jira/browse/HBASE-21538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21538: -- Attachment: HBASE-21538-HBASE-21512-v3.patch > Rewrite RegionReplicaFlushHandler to use AsyncClusterConnection > --- > > Key: HBASE-21538 > URL: https://issues.apache.org/jira/browse/HBASE-21538 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Attachments: HBASE-21538-HBASE-21512-v1.patch, > HBASE-21538-HBASE-21512-v2.patch, HBASE-21538-HBASE-21512-v2.patch, > HBASE-21538-HBASE-21512-v3.patch, HBASE-21538-HBASE-21512.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21538) Rewrite RegionReplicaFlushHandler to use AsyncClusterConnection
[ https://issues.apache.org/jira/browse/HBASE-21538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733893#comment-16733893 ] Duo Zhang commented on HBASE-21538: --- Review board link: https://reviews.apache.org/r/69666/ > Rewrite RegionReplicaFlushHandler to use AsyncClusterConnection > --- > > Key: HBASE-21538 > URL: https://issues.apache.org/jira/browse/HBASE-21538 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Attachments: HBASE-21538-HBASE-21512-v1.patch, > HBASE-21538-HBASE-21512-v2.patch, HBASE-21538-HBASE-21512-v2.patch, > HBASE-21538-HBASE-21512-v3.patch, HBASE-21538-HBASE-21512.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21671) Rewrite RegionReplicaReplicationEndpoint to use AsyncClusterConnection
Duo Zhang created HBASE-21671: - Summary: Rewrite RegionReplicaReplicationEndpoint to use AsyncClusterConnection Key: HBASE-21671 URL: https://issues.apache.org/jira/browse/HBASE-21671 Project: HBase Issue Type: Sub-task Reporter: Duo Zhang -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21588) Procedure v2 wal splitting implementation
[
https://issues.apache.org/jira/browse/HBASE-21588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733901#comment-16733901
]
Hadoop QA commented on HBASE-21588:
---
| (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 7 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
23s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
11s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
44s{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} 5m
2s{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
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s{color} | {color:green} The patch passed checkstyle in hbase-protocol-shaded
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s{color} | {color:green} The patch passed checkstyle in hbase-common {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
9s{color} | {color:green} hbase-server: The patch generated 0 new + 271
unchanged - 1 fixed = 271 total (was 272) {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
11s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 39s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
1m 30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
54s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
33s{color} | {color:green} hbase-protocol-shaded in the patch passed. {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}227m 58s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
18s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}283m 56s{color} |
{color:black} {c
