[jira] [Commented] (HBASE-20474) Show non-RPC tasks on master/regionserver Web UI by default
[
https://issues.apache.org/jira/browse/HBASE-20474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447650#comment-16447650
]
Hadoop QA commented on HBASE-20474:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
21s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}163m 15s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}173m 32s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestSnapshotCloneIndependence |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20474 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12920228/HBASE-20474.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux 916a64175dc2 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11
12:16:42 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 193359ffd2 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/12593/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12593/testReport/ |
| Max. process+thread count | 4294 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12593/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Show non-RPC tasks on master/regionserver Web UI by default
>
>
> Key: HBASE-20474
> URL: https://issues.apache.org/jira/browse/HBASE-20474
> Project: HBase
> Issue Type: Improvement
> Components: UI
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20474.master.001.patch
>
>
> Now, when opening master or regionserver pages, all tasks will be displayed
> on the page, however, but in most cases we will pay more attention to non-RPC
> tasks.
> In addition, if all tasks are displayed by default, a large number of pages
> will be occupied.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20475) Fix the flaky TestReplicationDroppedTables unit test.
Zheng Hu created HBASE-20475: Summary: Fix the flaky TestReplicationDroppedTables unit test. Key: HBASE-20475 URL: https://issues.apache.org/jira/browse/HBASE-20475 Project: HBase Issue Type: Bug Affects Versions: 2.1.0 Reporter: Zheng Hu Assignee: Zheng Hu Fix For: 3.0.0, 2.1.0 See https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[ https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20456: -- Attachment: HBASE-20456-HBASE-19064.patch > Support removing a ReplicationSourceShipper for a special wal group > --- > > Key: HBASE-20456 > URL: https://issues.apache.org/jira/browse/HBASE-20456 > Project: HBase > Issue Type: Sub-task > Components: Replication, wal >Reporter: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20456-HBASE-19064.patch > > > For the multi wal implementation, if a new group is created, then we will > always open a wal writer for it, even if no one uses it later. But for sync > replication, if the peer is transited to DA or S from A, the special wal will > be closed and there will be no more wal files for it so we need to close the > shipper -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[ https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20456: -- Assignee: Duo Zhang Fix Version/s: HBASE-19064 Status: Patch Available (was: Open) > Support removing a ReplicationSourceShipper for a special wal group > --- > > Key: HBASE-20456 > URL: https://issues.apache.org/jira/browse/HBASE-20456 > Project: HBase > Issue Type: Sub-task > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20456-HBASE-19064.patch > > > For the multi wal implementation, if a new group is created, then we will > always open a wal writer for it, even if no one uses it later. But for sync > replication, if the peer is transited to DA or S from A, the special wal will > be closed and there will be no more wal files for it so we need to close the > shipper -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[ https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20456: -- Component/s: wal Replication > Support removing a ReplicationSourceShipper for a special wal group > --- > > Key: HBASE-20456 > URL: https://issues.apache.org/jira/browse/HBASE-20456 > Project: HBase > Issue Type: Sub-task > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20456-HBASE-19064.patch > > > For the multi wal implementation, if a new group is created, then we will > always open a wal writer for it, even if no one uses it later. But for sync > replication, if the peer is transited to DA or S from A, the special wal will > be closed and there will be no more wal files for it so we need to close the > shipper -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19782) Reject the replication request when peer is DA or A state
[ https://issues.apache.org/jira/browse/HBASE-19782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447688#comment-16447688 ] Zheng Hu commented on HBASE-19782: -- Pushed to branch HBASE-19064, Thanks [~Apache9] for reviewing. > Reject the replication request when peer is DA or A state > - > > Key: HBASE-19782 > URL: https://issues.apache.org/jira/browse/HBASE-19782 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-19064-HBASE-19782.v1.patch, > HBASE-19064-HBASE-19782.v2.patch, HBASE-19782.HBASE-19064.v2.patch, > HBASE-19782.HBASE-19064.v2.patch, HBASE-19782.HBASE-19064.v3.patch, > HBASE-19782.HBASE-19064.v4.patch, HBASE-19782.HBASE-19064.v4.patch, > HBASE-19782.HBASE-19064.v4.patch, HBASE-19782.HBASE-19064.v5.patch, > HBASE-19782.HBASE-19064.v5.patch, HBASE-19782.HBASE-19064.v6.patch, > HBASE-19782.HBASE-19064.v7.patch, HBASE-19782.HBASE-19064.v8.patch > > > According to the design doc, we'll initialize both of the cluster state to > DA after added the bidirectional replication path. and when a cluster in > DA state, it'll reject replication request. > so for cluster A and B in state DA, if any received replication entry whose > table or namespace match the peer,the cluster will skip to apply into > its local rs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[ https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447692#comment-16447692 ] Duo Zhang commented on HBASE-20456: --- Review board link: https://reviews.apache.org/r/66756/ > Support removing a ReplicationSourceShipper for a special wal group > --- > > Key: HBASE-20456 > URL: https://issues.apache.org/jira/browse/HBASE-20456 > Project: HBase > Issue Type: Sub-task > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20456-HBASE-19064.patch > > > For the multi wal implementation, if a new group is created, then we will > always open a wal writer for it, even if no one uses it later. But for sync > replication, if the peer is transited to DA or S from A, the special wal will > be closed and there will be no more wal files for it so we need to close the > shipper -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20476) Fix the flaky TestReplicationSmallTests unit test
Zheng Hu created HBASE-20476: Summary: Fix the flaky TestReplicationSmallTests unit test Key: HBASE-20476 URL: https://issues.apache.org/jira/browse/HBASE-20476 Project: HBase Issue Type: Bug Reporter: Zheng Hu Assignee: Zheng Hu See https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19782) Reject the replication request when peer is DA or A state
[ https://issues.apache.org/jira/browse/HBASE-19782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-19782: - Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) > Reject the replication request when peer is DA or A state > - > > Key: HBASE-19782 > URL: https://issues.apache.org/jira/browse/HBASE-19782 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-19064-HBASE-19782.v1.patch, > HBASE-19064-HBASE-19782.v2.patch, HBASE-19782.HBASE-19064.v2.patch, > HBASE-19782.HBASE-19064.v2.patch, HBASE-19782.HBASE-19064.v3.patch, > HBASE-19782.HBASE-19064.v4.patch, HBASE-19782.HBASE-19064.v4.patch, > HBASE-19782.HBASE-19064.v4.patch, HBASE-19782.HBASE-19064.v5.patch, > HBASE-19782.HBASE-19064.v5.patch, HBASE-19782.HBASE-19064.v6.patch, > HBASE-19782.HBASE-19064.v7.patch, HBASE-19782.HBASE-19064.v8.patch > > > According to the design doc, we'll initialize both of the cluster state to > DA after added the bidirectional replication path. and when a cluster in > DA state, it'll reject replication request. > so for cluster A and B in state DA, if any received replication entry whose > table or namespace match the peer,the cluster will skip to apply into > its local rs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[
https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447694#comment-16447694
]
Hadoop QA commented on HBASE-20456:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s{color}
| {color:red} HBASE-20456 does not apply to HBASE-19064. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.7.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-20456 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12920241/HBASE-20456-HBASE-19064.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12595/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Support removing a ReplicationSourceShipper for a special wal group
> ---
>
> Key: HBASE-20456
> URL: https://issues.apache.org/jira/browse/HBASE-20456
> Project: HBase
> Issue Type: Sub-task
> Components: Replication, wal
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: HBASE-19064
>
> Attachments: HBASE-20456-HBASE-19064.patch
>
>
> For the multi wal implementation, if a new group is created, then we will
> always open a wal writer for it, even if no one uses it later. But for sync
> replication, if the peer is transited to DA or S from A, the special wal will
> be closed and there will be no more wal files for it so we need to close the
> shipper
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20476) Fix the flaky TestReplicationSmallTests unit test
[ https://issues.apache.org/jira/browse/HBASE-20476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447697#comment-16447697 ] Zheng Hu commented on HBASE-20476: -- And need to fix the flaky TestReplicationChangingPeerRegionservers too. > Fix the flaky TestReplicationSmallTests unit test > - > > Key: HBASE-20476 > URL: https://issues.apache.org/jira/browse/HBASE-20476 > Project: HBase > Issue Type: Bug >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > > See > https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[ https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20456: -- Attachment: HBASE-20456-HBASE-19064-v1.patch > Support removing a ReplicationSourceShipper for a special wal group > --- > > Key: HBASE-20456 > URL: https://issues.apache.org/jira/browse/HBASE-20456 > Project: HBase > Issue Type: Sub-task > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20456-HBASE-19064-v1.patch, > HBASE-20456-HBASE-19064.patch > > > For the multi wal implementation, if a new group is created, then we will > always open a wal writer for it, even if no one uses it later. But for sync > replication, if the peer is transited to DA or S from A, the special wal will > be closed and there will be no more wal files for it so we need to close the > shipper -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20472) InfoServer doesnot honour any acl set by the admin
[
https://issues.apache.org/jira/browse/HBASE-20472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447754#comment-16447754
]
Hadoop QA commented on HBASE-20472:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
29s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
44s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
46s{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
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
27s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
10s{color} | {color:red} hbase-server: The patch generated 3 new + 0 unchanged
- 0 fixed = 3 total (was 0) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
47s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 16s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
6s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
31s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
51s{color} | {color:green} hbase-http in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}124m
48s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
7s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}182m 36s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20472 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12920171/HBASE-20472.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux df21288ac89c 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev
[jira] [Updated] (HBASE-20458) Support removing a WAL from LogRoller
[ https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-20458: --- Attachment: HBASE-20458.HBASE-19064.001.patch > Support removing a WAL from LogRoller > - > > Key: HBASE-20458 > URL: https://issues.apache.org/jira/browse/HBASE-20458 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-20458.HBASE-19064.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20458) Support removing a WAL from LogRoller
[ https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-20458: --- Status: Patch Available (was: Open) > Support removing a WAL from LogRoller > - > > Key: HBASE-20458 > URL: https://issues.apache.org/jira/browse/HBASE-20458 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-20458.HBASE-19064.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20458) Support removing a WAL from LogRoller
[ https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447778#comment-16447778 ] Duo Zhang commented on HBASE-20458: --- I think we can just modify the code in AbstractFSWAL? For now, if the WAL is closed it just returns after a debug log. We can make it throw an exception instead and catch it in LogRoller. > Support removing a WAL from LogRoller > - > > Key: HBASE-20458 > URL: https://issues.apache.org/jira/browse/HBASE-20458 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-20458.HBASE-19064.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20458) Support removing a WAL from LogRoller
[
https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447803#comment-16447803
]
Hadoop QA commented on HBASE-20458:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} HBASE-19064 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
37s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
29s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
57s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
5s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
58s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} HBASE-19064 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 1m
41s{color} | {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} shadedjars {color} | {color:red} 3m
0s{color} | {color:red} patch has 11 errors when building our shaded downstream
artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
38s{color} | {color:red} The patch causes 11 errors with Hadoop v2.6.5. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m
18s{color} | {color:red} The patch causes 11 errors with Hadoop v2.7.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m
4s{color} | {color:red} The patch causes 11 errors with Hadoop v3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 38s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 30m 25s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20458 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12920247/HBASE-20458.HBASE-19064.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 0bd390b14c75 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | HBASE-19064 / afd78256c5 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8
[jira] [Updated] (HBASE-20427) thrift.jsp displays "Framed transport" incorrectly
[
https://issues.apache.org/jira/browse/HBASE-20427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi updated HBASE-20427:
--
Resolution: Fixed
Fix Version/s: 2.1.0
Status: Resolved (was: Patch Available)
Pushed to branch-2.0+, resolving.
> thrift.jsp displays "Framed transport" incorrectly
> ---
>
> Key: HBASE-20427
> URL: https://issues.apache.org/jira/browse/HBASE-20427
> Project: HBase
> Issue Type: Bug
> Components: Thrift
>Affects Versions: 2.0.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 2.0.0
>
> Attachments: HBASE-20427.master.001.patch,
> HBASE-20427.master.002.patch, HBASE-20427.master.003.patch
>
>
> According to thrift usage text:
> {code}
> -nonblocking Use the TNonblockingServer This implies the
>framed transport.
> {code}
> But the web page at port 9095 indicates {{framed = false}} when I start it
> with {{-nonblocking}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HBASE-20473) Ineffective INFO logging adjustment in HFilePerformanceEvaluation
[
https://issues.apache.org/jira/browse/HBASE-20473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu resolved HBASE-20473.
Resolution: Not A Problem
> Ineffective INFO logging adjustment in HFilePerformanceEvaluation
> -
>
> Key: HBASE-20473
> URL: https://issues.apache.org/jira/browse/HBASE-20473
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Priority: Minor
>
> {code}
> // Disable verbose INFO logging from org.apache.hadoop.io.compress.CodecPool
> static {
> System.setProperty("org.apache.commons.logging.Log",
> "org.apache.commons.logging.impl.SimpleLog");
> {code}
> The above code has no effect since we're migrating away from commons-logging.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20425) Do not write the cluster id of the current active cluster when writing remote WAL
[ https://issues.apache.org/jira/browse/HBASE-20425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-20425: - Attachment: HBASE-20425.HBASE-19064.v1.patch > Do not write the cluster id of the current active cluster when writing remote > WAL > - > > Key: HBASE-20425 > URL: https://issues.apache.org/jira/browse/HBASE-20425 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-20425.HBASE-19064.v1.patch > > > The wal entries which are replayed when converting a cluster from S to DA > need to be replicated back to the old A cluster. if we write the cluster id > of A into the wal entries, we will skip replicating them... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20425) Do not write the cluster id of the current active cluster when writing remote WAL
[ https://issues.apache.org/jira/browse/HBASE-20425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-20425: - Attachment: HBASE-20425.HBASE-19064.v1.patch > Do not write the cluster id of the current active cluster when writing remote > WAL > - > > Key: HBASE-20425 > URL: https://issues.apache.org/jira/browse/HBASE-20425 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-20425.HBASE-19064.v1.patch, > HBASE-20425.HBASE-19064.v1.patch > > > The wal entries which are replayed when converting a cluster from S to DA > need to be replicated back to the old A cluster. if we write the cluster id > of A into the wal entries, we will skip replicating them... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20425) Do not write the cluster id of the current active cluster when writing remote WAL
[ https://issues.apache.org/jira/browse/HBASE-20425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447834#comment-16447834 ] Zheng Hu commented on HBASE-20425: -- Checked the code, the rs only attach the cluster id into WALs in ReplicationSouce (by ClusterMarkingEntryFilter), so it won't add clusterIds when write the remote WAL in theory. And I've write a UT for this case, and it passed. IMO, we just need to commit the UT to ensure that remote WALs won't have the cluster id of active cluster. > Do not write the cluster id of the current active cluster when writing remote > WAL > - > > Key: HBASE-20425 > URL: https://issues.apache.org/jira/browse/HBASE-20425 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-20425.HBASE-19064.v1.patch, > HBASE-20425.HBASE-19064.v1.patch > > > The wal entries which are replayed when converting a cluster from S to DA > need to be replicated back to the old A cluster. if we write the cluster id > of A into the wal entries, we will skip replicating them... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20425) Do not write the cluster id of the current active cluster when writing remote WAL
[ https://issues.apache.org/jira/browse/HBASE-20425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-20425: - Attachment: (was: HBASE-20425.HBASE-19064.v1.patch) > Do not write the cluster id of the current active cluster when writing remote > WAL > - > > Key: HBASE-20425 > URL: https://issues.apache.org/jira/browse/HBASE-20425 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-20425.HBASE-19064.v1.patch > > > The wal entries which are replayed when converting a cluster from S to DA > need to be replicated back to the old A cluster. if we write the cluster id > of A into the wal entries, we will skip replicating them... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20458) Support removing a WAL from LogRoller
[ https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447837#comment-16447837 ] Guanghao Zhang commented on HBASE-20458: Will upload a new patch later. > Support removing a WAL from LogRoller > - > > Key: HBASE-20458 > URL: https://issues.apache.org/jira/browse/HBASE-20458 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-20458.HBASE-19064.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20458) Support removing a WAL from LogRoller
[
https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447835#comment-16447835
]
Guanghao Zhang commented on HBASE-20458:
{quote}I think we can just modify the code in AbstractFSWAL?
{quote}
This may only happened for DualAsyncFSWAL? But if a AbstractFSWAL was closed,
we should remove it from LogRoller, too...
> Support removing a WAL from LogRoller
> -
>
> Key: HBASE-20458
> URL: https://issues.apache.org/jira/browse/HBASE-20458
> Project: HBase
> Issue Type: Sub-task
>Reporter: Duo Zhang
>Assignee: Guanghao Zhang
>Priority: Major
> Attachments: HBASE-20458.HBASE-19064.001.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20425) Do not write the cluster id of the current active cluster when writing remote WAL
[ https://issues.apache.org/jira/browse/HBASE-20425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-20425: - Status: Patch Available (was: Open) > Do not write the cluster id of the current active cluster when writing remote > WAL > - > > Key: HBASE-20425 > URL: https://issues.apache.org/jira/browse/HBASE-20425 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-20425.HBASE-19064.v1.patch > > > The wal entries which are replayed when converting a cluster from S to DA > need to be replicated back to the old A cluster. if we write the cluster id > of A into the wal entries, we will skip replicating them... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20425) Do not write the cluster id of the current active cluster when writing remote WAL
[ https://issues.apache.org/jira/browse/HBASE-20425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447844#comment-16447844 ] Duo Zhang commented on HBASE-20425: --- OK, so we only add the cluster id when we replicate the entries out. > Do not write the cluster id of the current active cluster when writing remote > WAL > - > > Key: HBASE-20425 > URL: https://issues.apache.org/jira/browse/HBASE-20425 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-20425.HBASE-19064.v1.patch > > > The wal entries which are replayed when converting a cluster from S to DA > need to be replicated back to the old A cluster. if we write the cluster id > of A into the wal entries, we will skip replicating them... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20458) Support removing a WAL from LogRoller
[ https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-20458: --- Attachment: HBASE-20458.HBASE-19064.002.patch > Support removing a WAL from LogRoller > - > > Key: HBASE-20458 > URL: https://issues.apache.org/jira/browse/HBASE-20458 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-20458.HBASE-19064.001.patch, > HBASE-20458.HBASE-19064.002.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20458) Support removing a WAL from LogRoller
[ https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-20458: --- Attachment: HBASE-20458.HBASE-19064.003.patch > Support removing a WAL from LogRoller > - > > Key: HBASE-20458 > URL: https://issues.apache.org/jira/browse/HBASE-20458 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-20458.HBASE-19064.001.patch, > HBASE-20458.HBASE-19064.002.patch, HBASE-20458.HBASE-19064.003.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20458) Support removing a WAL from LogRoller
[ https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-20458: --- Attachment: HBASE-20458.HBASE-19064.004.patch > Support removing a WAL from LogRoller > - > > Key: HBASE-20458 > URL: https://issues.apache.org/jira/browse/HBASE-20458 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-20458.HBASE-19064.001.patch, > HBASE-20458.HBASE-19064.002.patch, HBASE-20458.HBASE-19064.003.patch, > HBASE-20458.HBASE-19064.004.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[ https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20456: -- Attachment: HBASE-20456-HBASE-19064-v2.patch > Support removing a ReplicationSourceShipper for a special wal group > --- > > Key: HBASE-20456 > URL: https://issues.apache.org/jira/browse/HBASE-20456 > Project: HBase > Issue Type: Sub-task > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20456-HBASE-19064-v1.patch, > HBASE-20456-HBASE-19064-v2.patch, HBASE-20456-HBASE-19064.patch > > > For the multi wal implementation, if a new group is created, then we will > always open a wal writer for it, even if no one uses it later. But for sync > replication, if the peer is transited to DA or S from A, the special wal will > be closed and there will be no more wal files for it so we need to close the > shipper -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[ https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447940#comment-16447940 ] Duo Zhang commented on HBASE-20456: --- Talked with [~zghaobac] offline, for peer removal we just remove the ReplicationSource directly so no problem. Let me see if we can do this in the way described above, i.e, always write wal to a special group, even if it is in DA or S. > Support removing a ReplicationSourceShipper for a special wal group > --- > > Key: HBASE-20456 > URL: https://issues.apache.org/jira/browse/HBASE-20456 > Project: HBase > Issue Type: Sub-task > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20456-HBASE-19064-v1.patch, > HBASE-20456-HBASE-19064-v2.patch, HBASE-20456-HBASE-19064.patch > > > For the multi wal implementation, if a new group is created, then we will > always open a wal writer for it, even if no one uses it later. But for sync > replication, if the peer is transited to DA or S from A, the special wal will > be closed and there will be no more wal files for it so we need to close the > shipper -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[
https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447969#comment-16447969
]
Hadoop QA commented on HBASE-20456:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{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} HBASE-19064 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
52s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
30s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
0s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
7s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
51s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
25s{color} | {color:green} HBASE-19064 passed {color} |
|| || || || {color:brown} Patch Compile Tests {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} 1m
31s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 1m 31s{color}
| {color:red} hbase-server generated 1 new + 187 unchanged - 1 fixed = 188
total (was 188) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
57s{color} | {color:red} hbase-server: The patch generated 1 new + 10 unchanged
- 0 fixed = 11 total (was 10) {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
10s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
13m 2s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
27s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}108m 28s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
16s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}150m 28s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.replication.TestSyncReplicationActive |
| | hadoop.hbase.replication.regionserver.TestWALEntryStream |
| | hadoop.hbase.replication.regionserver.TestReplicationSourceManagerZkImpl |
| | hadoop.hbase.TestCheckTestClasses |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20456 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12920245/HBASE-20456-HBASE-19064-v1.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 4d05586fb569 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | HBASE-19064 / afd78256c5 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_1
[jira] [Commented] (HBASE-20425) Do not write the cluster id of the current active cluster when writing remote WAL
[
https://issues.apache.org/jira/browse/HBASE-20425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448052#comment-16448052
]
Hadoop QA commented on HBASE-20425:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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} HBASE-19064 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
2s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
42s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
58s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
11s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} HBASE-19064 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
3s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
14m 56s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}107m
7s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}154m 26s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20425 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12920256/HBASE-20425.HBASE-19064.v1.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux c15886da570b 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | HBASE-19064 / afd78256c5 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12599/testReport/ |
| Max. process+thread count | 4239 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12599/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was
[jira] [Commented] (HBASE-20465) Fix TestEnableRSGroup flaky
[
https://issues.apache.org/jira/browse/HBASE-20465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448054#comment-16448054
]
Hudson commented on HBASE-20465:
Results for branch master
[build #309 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/309/]: (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/master/309//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/master/309//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/master/309//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Fix TestEnableRSGroup flaky
> ---
>
> Key: HBASE-20465
> URL: https://issues.apache.org/jira/browse/HBASE-20465
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Affects Versions: 2.0.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20465.master.001.patch
>
>
> Most recent {{TestEnableRSGroup}} tests failed on branch-2.0 according to our
> flaky dashboard.
> {code}
> java.lang.AssertionError
> at
> org.apache.hadoop.hbase.rsgroup.TestEnableRSGroup.testEnableRSGroup(TestEnableRSGroup.java:80)
> {code}
> TestEnableRSGroup:80:
> {code:java}
> // check if master started successfully
> assertTrue(TEST_UTIL.getMiniHBaseCluster().getMaster() != null);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20470) [2.0.0RC1] has broken unit tests...
[
https://issues.apache.org/jira/browse/HBASE-20470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448053#comment-16448053
]
Hudson commented on HBASE-20470:
Results for branch master
[build #309 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/309/]: (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/master/309//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/master/309//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/master/309//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> [2.0.0RC1] has broken unit tests...
>
>
> Key: HBASE-20470
> URL: https://issues.apache.org/jira/browse/HBASE-20470
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
>Priority: Major
> Attachments: HBASE-20470.branch-2.0.001.patch,
> HBASE-20470.branch-2.0.002.patch, HBASE-20470.branch-2.0.003.patch,
> HBASE-20470.branch-2.0.003.patch
>
>
> Found by [~uagashe] I think its because some depend on IMC and it was
> disabled just before I made RC1. Let me try a nothing change and see.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20425) Do not write the cluster id of the current active cluster when writing remote WAL
[ https://issues.apache.org/jira/browse/HBASE-20425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448063#comment-16448063 ] Duo Zhang commented on HBASE-20425: --- +1. > Do not write the cluster id of the current active cluster when writing remote > WAL > - > > Key: HBASE-20425 > URL: https://issues.apache.org/jira/browse/HBASE-20425 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-20425.HBASE-19064.v1.patch > > > The wal entries which are replayed when converting a cluster from S to DA > need to be replicated back to the old A cluster. if we write the cluster id > of A into the wal entries, we will skip replicating them... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20458) Support removing a WAL from LogRoller
[
https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448085#comment-16448085
]
Hadoop QA commented on HBASE-20458:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
33s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} HBASE-19064 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
7s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
45s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
11s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
55s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
25s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | {color:green} HBASE-19064 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
44s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
13s{color} | {color:red} hbase-server: The patch generated 1 new + 6 unchanged
- 0 fixed = 7 total (was 6) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
8s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 16s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
22s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
31s{color} | {color:red} hbase-server generated 3 new + 2 unchanged - 0 fixed =
5 total (was 2) {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}127m
32s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
24s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}176m 3s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20458 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12920259/HBASE-20458.HBASE-19064.004.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 269a66eaaab1 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | HBASE-19064 / afd78256c5 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/12598/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
|
[jira] [Comment Edited] (HBASE-20466) Consistently use override mechanism for exempt classes in CoprocessClassloader
[ https://issues.apache.org/jira/browse/HBASE-20466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448094#comment-16448094 ] Rich Fecher edited comment on HBASE-20466 at 4/23/18 12:53 PM: --- v3 includes the suggested formatting change was (Author: rfecher): v3 include the suggested formatting change > Consistently use override mechanism for exempt classes in CoprocessClassloader > -- > > Key: HBASE-20466 > URL: https://issues.apache.org/jira/browse/HBASE-20466 > Project: HBase > Issue Type: Bug > Components: Coprocessors >Affects Versions: 2.0.0-beta-2, 1.4.3 >Reporter: Rich Fecher >Priority: Major > Attachments: HBASE-20466_master.patch, HBASE-20466_master_v2.patch, > HBASE-20466_master_v3.patch > > > RegionCoprocessorHost.testTableCoprocessorAttrs() use the inclusion list for > CoprocessorClassLoader. This issue is related to HBASE-15686. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20466) Consistently use override mechanism for exempt classes in CoprocessClassloader
[ https://issues.apache.org/jira/browse/HBASE-20466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Fecher updated HBASE-20466: Attachment: HBASE-20466_master_v3.patch > Consistently use override mechanism for exempt classes in CoprocessClassloader > -- > > Key: HBASE-20466 > URL: https://issues.apache.org/jira/browse/HBASE-20466 > Project: HBase > Issue Type: Bug > Components: Coprocessors >Affects Versions: 2.0.0-beta-2, 1.4.3 >Reporter: Rich Fecher >Priority: Major > Attachments: HBASE-20466_master.patch, HBASE-20466_master_v2.patch, > HBASE-20466_master_v3.patch > > > RegionCoprocessorHost.testTableCoprocessorAttrs() use the inclusion list for > CoprocessorClassLoader. This issue is related to HBASE-15686. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20466) Consistently use override mechanism for exempt classes in CoprocessClassloader
[ https://issues.apache.org/jira/browse/HBASE-20466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448094#comment-16448094 ] Rich Fecher edited comment on HBASE-20466 at 4/23/18 12:53 PM: --- v3 include the suggested formatting change was (Author: rfecher): v3 includs the suggested formatting change > Consistently use override mechanism for exempt classes in CoprocessClassloader > -- > > Key: HBASE-20466 > URL: https://issues.apache.org/jira/browse/HBASE-20466 > Project: HBase > Issue Type: Bug > Components: Coprocessors >Affects Versions: 2.0.0-beta-2, 1.4.3 >Reporter: Rich Fecher >Priority: Major > Attachments: HBASE-20466_master.patch, HBASE-20466_master_v2.patch, > HBASE-20466_master_v3.patch > > > RegionCoprocessorHost.testTableCoprocessorAttrs() use the inclusion list for > CoprocessorClassLoader. This issue is related to HBASE-15686. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20466) Consistently use override mechanism for exempt classes in CoprocessClassloader
[ https://issues.apache.org/jira/browse/HBASE-20466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448094#comment-16448094 ] Rich Fecher commented on HBASE-20466: - v3 includs the suggested formatting change > Consistently use override mechanism for exempt classes in CoprocessClassloader > -- > > Key: HBASE-20466 > URL: https://issues.apache.org/jira/browse/HBASE-20466 > Project: HBase > Issue Type: Bug > Components: Coprocessors >Affects Versions: 2.0.0-beta-2, 1.4.3 >Reporter: Rich Fecher >Priority: Major > Attachments: HBASE-20466_master.patch, HBASE-20466_master_v2.patch, > HBASE-20466_master_v3.patch > > > RegionCoprocessorHost.testTableCoprocessorAttrs() use the inclusion list for > CoprocessorClassLoader. This issue is related to HBASE-15686. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20458) Support removing a WAL from LogRoller
[
https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448101#comment-16448101
]
Hadoop QA commented on HBASE-20458:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} HBASE-19064 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
10s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
53s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
17s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
1s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
14s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} HBASE-19064 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
46s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
15s{color} | {color:red} hbase-server: The patch generated 1 new + 6 unchanged
- 0 fixed = 7 total (was 6) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
1s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 34s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
15s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
31s{color} | {color:red} hbase-server generated 3 new + 2 unchanged - 0 fixed =
5 total (was 2) {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}128m
25s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
24s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}177m 4s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20458 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12920259/HBASE-20458.HBASE-19064.004.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 01d7da41c9ab 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | HBASE-19064 / afd78256c5 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/12600/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
[jira] [Commented] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[ https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448118#comment-16448118 ] Duo Zhang commented on HBASE-20456: --- Fix failed UTs. > Support removing a ReplicationSourceShipper for a special wal group > --- > > Key: HBASE-20456 > URL: https://issues.apache.org/jira/browse/HBASE-20456 > Project: HBase > Issue Type: Sub-task > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20456-HBASE-19064-v1.patch, > HBASE-20456-HBASE-19064-v2.patch, HBASE-20456-HBASE-19064-v3.patch, > HBASE-20456-HBASE-19064.patch > > > For the multi wal implementation, if a new group is created, then we will > always open a wal writer for it, even if no one uses it later. But for sync > replication, if the peer is transited to DA or S from A, the special wal will > be closed and there will be no more wal files for it so we need to close the > shipper -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[ https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20456: -- Attachment: HBASE-20456-HBASE-19064-v3.patch > Support removing a ReplicationSourceShipper for a special wal group > --- > > Key: HBASE-20456 > URL: https://issues.apache.org/jira/browse/HBASE-20456 > Project: HBase > Issue Type: Sub-task > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20456-HBASE-19064-v1.patch, > HBASE-20456-HBASE-19064-v2.patch, HBASE-20456-HBASE-19064-v3.patch, > HBASE-20456-HBASE-19064.patch > > > For the multi wal implementation, if a new group is created, then we will > always open a wal writer for it, even if no one uses it later. But for sync > replication, if the peer is transited to DA or S from A, the special wal will > be closed and there will be no more wal files for it so we need to close the > shipper -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[ https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448131#comment-16448131 ] Duo Zhang commented on HBASE-20456: --- Discussed with [~zghaobac] again, the difficulty here is that, we assume that in DA state a region will not use the special WAL for sync replication peer, so when removing the peer we need to do nothing. So if we always use a special WAL then after removing the peer, the WAL is still there... And also, the wal files will be added to all replication sources, so even if we remove the peer, replication sources for other peers will still create a shipper for it. Another way maybe use the same group which we use in DA or S state, but we could also use multiwal, then we can not know the group unless we actual get a WAL instance... This is a bit ugly... We get a WAL using the old WALProvider, and then drop it and create our own WAL... > Support removing a ReplicationSourceShipper for a special wal group > --- > > Key: HBASE-20456 > URL: https://issues.apache.org/jira/browse/HBASE-20456 > Project: HBase > Issue Type: Sub-task > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20456-HBASE-19064-v1.patch, > HBASE-20456-HBASE-19064-v2.patch, HBASE-20456-HBASE-19064-v3.patch, > HBASE-20456-HBASE-19064.patch > > > For the multi wal implementation, if a new group is created, then we will > always open a wal writer for it, even if no one uses it later. But for sync > replication, if the peer is transited to DA or S from A, the special wal will > be closed and there will be no more wal files for it so we need to close the > shipper -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[
https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448132#comment-16448132
]
Hadoop QA commented on HBASE-20456:
---
| (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 1 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-19064 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
37s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
46s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
5s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
39s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
15s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} HBASE-19064 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
47s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 1m 47s{color}
| {color:red} hbase-server generated 1 new + 187 unchanged - 1 fixed = 188
total (was 188) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
9s{color} | {color:red} hbase-server: The patch generated 1 new + 10 unchanged
- 0 fixed = 11 total (was 10) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
46s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
13m 8s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}114m 39s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
22s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}158m 29s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.replication.regionserver.TestWALEntryStream
|
| | hadoop.hbase.replication.regionserver.TestReplicationSourceManagerZkImpl |
| | hadoop.hbase.util.TestMiniClusterLoadParallel |
| | hadoop.hbase.util.TestHBaseFsckReplication |
| | hadoop.hbase.TestCheckTestClasses |
| | hadoop.hbase.util.TestRegionSplitter |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20456 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12920265/HBASE-20456-HBASE-19064-v2.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 9e2822d68b7f 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | HBASE-19064 / afd78256c5 |
| maven | version: Apache Maven 3.5.3
(
[jira] [Commented] (HBASE-20465) Fix TestEnableRSGroup flaky
[
https://issues.apache.org/jira/browse/HBASE-20465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448168#comment-16448168
]
Balazs Meszaros commented on HBASE-20465:
-
It is gone from the flaky dashboard :)
> Fix TestEnableRSGroup flaky
> ---
>
> Key: HBASE-20465
> URL: https://issues.apache.org/jira/browse/HBASE-20465
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Affects Versions: 2.0.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20465.master.001.patch
>
>
> Most recent {{TestEnableRSGroup}} tests failed on branch-2.0 according to our
> flaky dashboard.
> {code}
> java.lang.AssertionError
> at
> org.apache.hadoop.hbase.rsgroup.TestEnableRSGroup.testEnableRSGroup(TestEnableRSGroup.java:80)
> {code}
> TestEnableRSGroup:80:
> {code:java}
> // check if master started successfully
> assertTrue(TEST_UTIL.getMiniHBaseCluster().getMaster() != null);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20426) Give up replicating anything in S state
[ https://issues.apache.org/jira/browse/HBASE-20426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20426: -- Attachment: HBASE-20426-UT.patch > Give up replicating anything in S state > --- > > Key: HBASE-20426 > URL: https://issues.apache.org/jira/browse/HBASE-20426 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Priority: Major > Attachments: HBASE-20426-UT.patch > > > When we transit the remote S cluster to DA, and then transit the old A > cluster to S, it is possible that we still have some entries which have not > been replicated yet for the old A cluster, and then the async replication > will be blocked. > And this may also lead to data inconsistency after we transit it to DA back > later as these entries will be replicated again, but the new data which are > replicated from the remote cluster will not be replicated back, which > introduce a whole in the replication. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20426) Give up replicating anything in S state
[ https://issues.apache.org/jira/browse/HBASE-20426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448175#comment-16448175 ] Duo Zhang commented on HBASE-20426: --- A UT to represent the problem. Need HBASE-20456 in place before applying it. > Give up replicating anything in S state > --- > > Key: HBASE-20426 > URL: https://issues.apache.org/jira/browse/HBASE-20426 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Priority: Major > Attachments: HBASE-20426-UT.patch > > > When we transit the remote S cluster to DA, and then transit the old A > cluster to S, it is possible that we still have some entries which have not > been replicated yet for the old A cluster, and then the async replication > will be blocked. > And this may also lead to data inconsistency after we transit it to DA back > later as these entries will be replicated again, but the new data which are > replicated from the remote cluster will not be replicated back, which > introduce a whole in the replication. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20414) TestLockProcedure#testMultipleLocks may fail on slow machine
[
https://issues.apache.org/jira/browse/HBASE-20414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448246#comment-16448246
]
Ted Yu commented on HBASE-20414:
Yes.
Please note that the failing subtest uses multiple calls to {{queueLock}},
leading to not enough time for half of the LOCAL_LOCKS_TIMEOUT.
The other subtests only call {{queueLock}} once.
> TestLockProcedure#testMultipleLocks may fail on slow machine
>
>
> Key: HBASE-20414
> URL: https://issues.apache.org/jira/browse/HBASE-20414
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 20414.v1.txt
>
>
> Here was recent failure :
> https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/172/testReport/junit/org.apache.hadoop.hbase.master.locking/TestLockProcedure/health_checks___yetus_jdk8_hadoop2_checks___testMultipleLocks/
> {code}
> java.lang.AssertionError: expected: but was:
> at
> org.apache.hadoop.hbase.master.locking.TestLockProcedure.sendHeartbeatAndCheckLocked(TestLockProcedure.java:221)
> at
> org.apache.hadoop.hbase.master.locking.TestLockProcedure.testMultipleLocks(TestLockProcedure.java:311)
> {code}
> In the test output, we can see this:
> {code}
> 2018-04-13 20:19:54,230 DEBUG [Time-limited test]
> locking.TestLockProcedure(225): Proc id 22 : LOCKED.
> ...
> 2018-04-13 20:19:55,529 DEBUG [Time-limited test]
> procedure2.ProcedureExecutor(865): Stored pid=26, state=RUNNABLE;
> org.apache.hadoop.hbase.master.locking.LockProcedure
> regions=a7f9adfd047350eabb199a39564ba4db,c1e297609590b707233a2f9c8bb51fa1,
> type=EXCLUSIVE
> 2018-04-13 20:19:56,230 DEBUG [ProcExecTimeout] locking.LockProcedure(207):
> Timeout failure ProcedureEvent for pid=22, state=WAITING_TIMEOUT;
> org.apache.hadoop.hbase.master.locking.LockProcedure, namespace=namespace,
> type=EXCLUSIVE, ready=false, [pid=22, state=WAITING_TIMEOUT;
> org.apache.hadoop.hbase.master.locking.LockProcedure, namespace=namespace,
> type=EXCLUSIVE]
> {code}
> After the pid=26 log, the code does this (1 second wait):
> {code}
> // Assert tables & region locks are waiting because of namespace lock.
> Thread.sleep(HEARTBEAT_TIMEOUT / 2);
> {code}
> On a slow machine (in the case above), there was only 730 msec between the
> queueing of regionsLock2 and the WAITING_TIMEOUT state of the nsLock. The 1
> second wait was too long, leading to assertion failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20466) Consistently use override mechanism for exempt classes in CoprocessClassloader
[ https://issues.apache.org/jira/browse/HBASE-20466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-20466: --- Resolution: Fixed Assignee: Rich Fecher Hadoop Flags: Reviewed Fix Version/s: 2.1.0 Status: Resolved (was: Patch Available) Thanks for the patch, Rich. I added space between ) and left curly in two places. > Consistently use override mechanism for exempt classes in CoprocessClassloader > -- > > Key: HBASE-20466 > URL: https://issues.apache.org/jira/browse/HBASE-20466 > Project: HBase > Issue Type: Bug > Components: Coprocessors >Affects Versions: 2.0.0-beta-2, 1.4.3 >Reporter: Rich Fecher >Assignee: Rich Fecher >Priority: Major > Fix For: 2.1.0 > > Attachments: HBASE-20466_master.patch, HBASE-20466_master_v2.patch, > HBASE-20466_master_v3.patch > > > RegionCoprocessorHost.testTableCoprocessorAttrs() use the inclusion list for > CoprocessorClassLoader. This issue is related to HBASE-15686. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20466) Consistently use override mechanism for exempt classes in CoprocessClassloader
[ https://issues.apache.org/jira/browse/HBASE-20466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448271#comment-16448271 ] Rich Fecher commented on HBASE-20466: - Thanks Ted! > Consistently use override mechanism for exempt classes in CoprocessClassloader > -- > > Key: HBASE-20466 > URL: https://issues.apache.org/jira/browse/HBASE-20466 > Project: HBase > Issue Type: Bug > Components: Coprocessors >Affects Versions: 2.0.0-beta-2, 1.4.3 >Reporter: Rich Fecher >Assignee: Rich Fecher >Priority: Major > Fix For: 2.1.0 > > Attachments: HBASE-20466_master.patch, HBASE-20466_master_v2.patch, > HBASE-20466_master_v3.patch > > > RegionCoprocessorHost.testTableCoprocessorAttrs() use the inclusion list for > CoprocessorClassLoader. This issue is related to HBASE-15686. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20466) Consistently use override mechanism for exempt classes in CoprocessClassloader
[
https://issues.apache.org/jira/browse/HBASE-20466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448337#comment-16448337
]
Hadoop QA commented on HBASE-20466:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
32s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
11s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
49s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
48s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
14m 59s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}122m
2s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}168m 12s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20466 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12920282/HBASE-20466_master_v3.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux deef69ee1799 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / e73ba582f2 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12602/testReport/ |
| Max. process+thread count | 4376 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12602/conso
[jira] [Created] (HBASE-20477) Document HeapMemoryTuner in refguide
stack created HBASE-20477: - Summary: Document HeapMemoryTuner in refguide Key: HBASE-20477 URL: https://issues.apache.org/jira/browse/HBASE-20477 Project: HBase Issue Type: Bug Components: documentation Reporter: stack This is an old facility that is in danger of disappearing because there is no mention in refguide and because it is private interface, it does not show in the user API. Add doc on how it works. It could probably do with a bit of testing too to make sure it working as advertised. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20477) Document HeapMemoryTuner in refguide
[ https://issues.apache.org/jira/browse/HBASE-20477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448405#comment-16448405 ] stack commented on HBASE-20477: --- Our [~jmspaggi] says this should be on by default which was sort of the idea originally; IIRC, it was the want-of-testing over time and at scale that prevented our defaulting it on. > Document HeapMemoryTuner in refguide > > > Key: HBASE-20477 > URL: https://issues.apache.org/jira/browse/HBASE-20477 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: stack >Priority: Major > Labels: beginner > > This is an old facility that is in danger of disappearing because there is no > mention in refguide and because it is private interface, it does not show in > the user API. Add doc on how it works. It could probably do with a bit of > testing too to make sure it working as advertised. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20477) Document HeapMemoryTuner in refguide
[ https://issues.apache.org/jira/browse/HBASE-20477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-20477: Fix Version/s: 3.0.0 > Document HeapMemoryTuner in refguide > > > Key: HBASE-20477 > URL: https://issues.apache.org/jira/browse/HBASE-20477 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: stack >Priority: Major > Labels: beginner > Fix For: 3.0.0 > > > This is an old facility that is in danger of disappearing because there is no > mention in refguide and because it is private interface, it does not show in > the user API. Add doc on how it works. It could probably do with a bit of > testing too to make sure it working as advertised. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20477) Document HeapMemoryTuner in refguide
[ https://issues.apache.org/jira/browse/HBASE-20477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-20477: Issue Type: Task (was: Bug) > Document HeapMemoryTuner in refguide > > > Key: HBASE-20477 > URL: https://issues.apache.org/jira/browse/HBASE-20477 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: stack >Priority: Major > Labels: beginner > Fix For: 3.0.0 > > > This is an old facility that is in danger of disappearing because there is no > mention in refguide and because it is private interface, it does not show in > the user API. Add doc on how it works. It could probably do with a bit of > testing too to make sure it working as advertised. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[
https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448425#comment-16448425
]
Hadoop QA commented on HBASE-20456:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{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 3 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-19064 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
55s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
47s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
13s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
1s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
18s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} HBASE-19064 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
48s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 1m 48s{color}
| {color:red} hbase-server generated 1 new + 187 unchanged - 1 fixed = 188
total (was 188) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
55s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
16m 31s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
35s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}146m 46s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
21s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}197m 20s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.master.procedure.TestModifyNamespaceProcedure |
| |
hadoop.hbase.master.balancer.TestStochasticLoadBalancerRegionReplicaHighReplication
|
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20456 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12920283/HBASE-20456-HBASE-19064-v3.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux dbe7646df1da 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | HBASE-19064 / afd78256c5 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| javac |
https://builds.apache.org/job/PreCommit-HBASE-Build/12603/artifact/patchprocess/diff-compile-javac-hba
[jira] [Commented] (HBASE-20444) Improve version comparison logic for HBase specific version string and add unit tests
[
https://issues.apache.org/jira/browse/HBASE-20444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448431#comment-16448431
]
Nihal Jain commented on HBASE-20444:
Is this the correct ordering for versions (Smaller to larger)?
{{"0.98.11", "0.99.11", "0.99.14", "1.99.14", "2.0.0-alpha-1",
"2.0.0-alpha-3",}}
{{ "2.0.0-beta-3", "2.0.0-SNAPSHOT", "2.0", "2.0.0-patch-123", "2.0.0.1",
"2.0.1"}}
> Improve version comparison logic for HBase specific version string and add
> unit tests
> -
>
> Key: HBASE-20444
> URL: https://issues.apache.org/jira/browse/HBASE-20444
> Project: HBase
> Issue Type: Improvement
>Reporter: Umesh Agashe
>Priority: Major
>
> As [~busbey] commented on HBASE-18792, current logic for comparing version
> strings in class org.apache.hadoop.hbase.util.VersionInfo is generic and
> needs to be improved:
> {code:java}
> if (index < s1.length) {
> // s1 is longer
> return 1;
> }
> {code}
> {quote}I think this is wrong? like version "2.0.0" should be after
> "2.0.0-SNAPSHOT". it's also after "2.0.0-alpha-3" or "2.0.0-beta-1".
> {quote}
> Also in other cases 2.0.0 should be before 2.0.0-patch- and 2.0.0.1. Also
> 2.0 should be before 2.0.1.
> {quote}Can we expand the versions checked in TestVersionInfo to include a)
> some "same major different minor", b) "same minor different maintenance", c)
> both of the above, but SNAPSHOT, d) "-alpha" / "-beta"?
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-6572) Tiered HFile storage
[ https://issues.apache.org/jira/browse/HBASE-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448432#comment-16448432 ] Andrew Purtell commented on HBASE-6572: --- Yes I think it is time to write it up, since it's going to be in 2.0.0. Please be sure to mention it is an experimental feature. > Tiered HFile storage > > > Key: HBASE-6572 > URL: https://issues.apache.org/jira/browse/HBASE-6572 > Project: HBase > Issue Type: Brainstorming >Reporter: Andrew Purtell >Priority: Major > > Consider how we might enable tiered HFile storage. If HDFS has the > capability, we could create certain files on solid state devices where they > might be frequently accessed, especially for random reads; and others (and by > default) on spinning media as before. We could support the move of frequently > read HFiles from spinning media to solid state. We already have CF statistics > for this, would only need to add requisite admin interface; could even > consider an autotiering option. > Dhruba Borthakur did some early work in this area and wrote up his findings: > http://hadoopblog.blogspot.com/2012/05/hadoop-and-solid-state-drives.html . > It is important to note the findings but I suggest most of the > recommendations are out of scope of this JIRA. This JIRA seeks to find an > initial use case that produces a reasonable benefit, and serves as a testbed > for further improvements. If I may paraphrase Dhruba's findings (any > misstatements and errors are mine): First, the DFSClient code paths introduce > significant latency, so the HDFS client (and presumably the DataNode, as the > next bottleneck) will need significant work to knock that down. Need to > investigate optimized (perhaps read-only) DFS clients, server side read and > caching strategies. Second, RegionServers are heavily threaded and this > imposes a lot of monitor contention and context switching cost. Need to > investigate reducing the number of threads in a RegionServer, nonblocking IO > and RPC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20444) Improve version comparison logic for HBase specific version string and add unit tests
[
https://issues.apache.org/jira/browse/HBASE-20444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448431#comment-16448431
]
Nihal Jain edited comment on HBASE-20444 at 4/23/18 4:54 PM:
-
Is this the correct ordering for versions (Smaller to larger)?
{{"0.98.11", "0.99.11", "0.99.14", "1.99.14", "2.0.0-alpha-1", "2.0.0-alpha-3",
"2.0.0-beta-3", "2.0.0-SNAPSHOT", "2.0", "2.0.0-patch-123", "2.0.0.1",
"2.0.1"}}
was (Author: nihaljain.cs):
Is this the correct ordering for versions (Smaller to larger)?
{{"0.98.11", "0.99.11", "0.99.14", "1.99.14", "2.0.0-alpha-1",
"2.0.0-alpha-3",}}
{{ "2.0.0-beta-3", "2.0.0-SNAPSHOT", "2.0", "2.0.0-patch-123", "2.0.0.1",
"2.0.1"}}
> Improve version comparison logic for HBase specific version string and add
> unit tests
> -
>
> Key: HBASE-20444
> URL: https://issues.apache.org/jira/browse/HBASE-20444
> Project: HBase
> Issue Type: Improvement
>Reporter: Umesh Agashe
>Priority: Major
>
> As [~busbey] commented on HBASE-18792, current logic for comparing version
> strings in class org.apache.hadoop.hbase.util.VersionInfo is generic and
> needs to be improved:
> {code:java}
> if (index < s1.length) {
> // s1 is longer
> return 1;
> }
> {code}
> {quote}I think this is wrong? like version "2.0.0" should be after
> "2.0.0-SNAPSHOT". it's also after "2.0.0-alpha-3" or "2.0.0-beta-1".
> {quote}
> Also in other cases 2.0.0 should be before 2.0.0-patch- and 2.0.0.1. Also
> 2.0 should be before 2.0.1.
> {quote}Can we expand the versions checked in TestVersionInfo to include a)
> some "same major different minor", b) "same minor different maintenance", c)
> both of the above, but SNAPSHOT, d) "-alpha" / "-beta"?
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20316) Backport HBASE-20229 "ConnectionImplementation.locateRegions() returns duplicated entries when region replication is on" to branch-1
[ https://issues.apache.org/jira/browse/HBASE-20316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448583#comment-16448583 ] huaxiang sun commented on HBASE-20316: -- I will commit shortly, thanks. > Backport HBASE-20229 "ConnectionImplementation.locateRegions() returns > duplicated entries when region replication is on" to branch-1 > > > Key: HBASE-20316 > URL: https://issues.apache.org/jira/browse/HBASE-20316 > Project: HBase > Issue Type: Sub-task > Components: backport >Reporter: stack >Assignee: Toshihiro Suzuki >Priority: Major > Attachments: HBASE-20229.branch-1.002.patch, > HBASE-20229.branch-1.002.patch, HBASE-20229.branch-1.002.patch, > HBASE-20229.branch-1.002.patch > > > Issue to backport parent to branch-1. Hope you don't mind my assigning it to > you [~brfrn169] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20468) RPC quota requests ineffective due to not counting multi-actions
[ https://issues.apache.org/jira/browse/HBASE-20468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448687#comment-16448687 ] Josh Elser commented on HBASE-20468: Primo, thanks, Andrew! > RPC quota requests ineffective due to not counting multi-actions > > > Key: HBASE-20468 > URL: https://issues.apache.org/jira/browse/HBASE-20468 > Project: HBase > Issue Type: Bug > Components: rpc >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: 2.1.0, 1.5.0, 1.3.3, 1.2.8, 2.0.1, 1.4.5 > > > Was digging into a problem with [~ankit.singhal] where setting RPC quotas on > number of requests wasn't having any effect on a multi-Get > Ankit did enough digging to find that this was because each RPC was being > treated as one request instead of the number of requests contained within the > RPC itself. > Thinking as an operator, this is a pretty ineffective control because a user > could just craft their API usage easily to work around any kind of limits I > want to set to control their impact on the system. TimeBasedLimiter is > assuming that one call to the quota code can only count as one request which > I think is just wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (HBASE-20468) RPC quota requests ineffective due to not counting multi-actions
[ https://issues.apache.org/jira/browse/HBASE-20468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-20468 started by Josh Elser. -- > RPC quota requests ineffective due to not counting multi-actions > > > Key: HBASE-20468 > URL: https://issues.apache.org/jira/browse/HBASE-20468 > Project: HBase > Issue Type: Bug > Components: rpc >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: 2.1.0, 1.5.0, 1.3.3, 1.2.8, 2.0.1, 1.4.5 > > > Was digging into a problem with [~ankit.singhal] where setting RPC quotas on > number of requests wasn't having any effect on a multi-Get > Ankit did enough digging to find that this was because each RPC was being > treated as one request instead of the number of requests contained within the > RPC itself. > Thinking as an operator, this is a pretty ineffective control because a user > could just craft their API usage easily to work around any kind of limits I > want to set to control their impact on the system. TimeBasedLimiter is > assuming that one call to the quota code can only count as one request which > I think is just wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20332) shaded mapreduce module shouldn't include hadoop
[
https://issues.apache.org/jira/browse/HBASE-20332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448829#comment-16448829
]
Sean Busbey commented on HBASE-20332:
-
{quote}
patch you uploaded appears to actually be 4 patches, the first three of which
have been committed.
{quote}
Right, it depended on them and they weren't committed at the time. I'll rebase
and omit them on the next version.
{quote}
hbase-anti needs to print a footer link, I can't even find the results by
poking in the build output patchprocess directory. (fine to do in a follow on
if you can manually link me to the results)
{quote}
hbase-anti doesn't output anything to a log file AFAICT. it just greps the
patch file itself and throws up a vote. I can update it to output to a log and
put something in the footer, but it's going to give line numbers in the patch
file. will that be too confusing?
{quote}
htrace is retiring. there is a chance that it will go back to using org.htrace
package space if it lives on somewhere. we'll address that if it happens, i
suppose.
are we supposed to still exclude htrace from the ban transitive deps enforcer
rule? this is getting confusing.
{quote}
yeah a problem for another day I think; it's a mess for sure. I don't believe
we can ban it from the transitive dependencies so long as Hadoop needs it to
run (which is does for Hadoop < 2.8).
{quote}
bravo on commenting why we need some of the dependencies. valiant effort, i'm
sure it will be stale in two weeks, but at least it was up to date once.
{quote}
It is my honor an privilege to push the rock up the hill a few more times. ;)
{quote}
do we end up with jackson 1/2 conflict between ourselves and hadoop? looks like
you massaged it all away, maybe? do we need to make BlockCacheUtil and
ObjectModel go away?
{quote}
As far as I know this patch maintains any previous massaging of jackson 1/2
conflicts and does no new massaging of such conflicts. Maybe I have a side
effect I'm not seeing though?
I'd very much like to see the JSON needs in core modules removed, but it looked
like more work than was wise to fold into this change since I want it in 1.y
and 2.y.
{quote}
so now we build a shaded with hadoop and shaded without hadoop MR artifact?
{quote}
Yes. I have another jira that's a sibling to this one to make a shaded client
artifact without hadoop as well. That one is harder because artifact naming
will likely make the 3.0 version breaking compared to earlier lines.
{quote}
did we not have a netty.hadoop.version defined before? could've sworn I've seen
it
{quote}
We definitely had netty.hadoop.version prior to this patch. But we forgot to
include it in the "defaults when no profile is active" section that we added
for non-maven build systems.
> shaded mapreduce module shouldn't include hadoop
>
>
> Key: HBASE-20332
> URL: https://issues.apache.org/jira/browse/HBASE-20332
> Project: HBase
> Issue Type: Sub-task
> Components: mapreduce, shading
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20332.0.patch, HBASE-20332.1.WIP.patch,
> HBASE-20332.2.WIP.patch, HBASE-20332.3.patch
>
>
> AFAICT, we should just entirely skip including hadoop in our shaded mapreduce
> module
> 1) Folks expect to run yarn / mr apps via {{hadoop jar}} / {{yarn jar}}
> 2) those commands include all the needed Hadoop jars in your classpath by
> default (both client side and in the containers)
> 3) If you try to use "user classpath first" for your job as a workaround
> (e.g. for some library your application needs that hadoop provides) then our
> inclusion of *some but not all* hadoop classes then causes everything to fall
> over because of mixing rewritten and non-rewritten hadoop classes
> 4) if you don't use "user classpath first" then all of our
> non-relocated-but-still-shaded hadoop classes are ignored anyways so we're
> just wasting space
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20427) thrift.jsp displays "Framed transport" incorrectly
[
https://issues.apache.org/jira/browse/HBASE-20427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448865#comment-16448865
]
Hudson commented on HBASE-20427:
Results for branch branch-2.0
[build #214 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/214/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/214//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/214//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/214//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> thrift.jsp displays "Framed transport" incorrectly
> ---
>
> Key: HBASE-20427
> URL: https://issues.apache.org/jira/browse/HBASE-20427
> Project: HBase
> Issue Type: Bug
> Components: Thrift
>Affects Versions: 2.0.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 2.0.0
>
> Attachments: HBASE-20427.master.001.patch,
> HBASE-20427.master.002.patch, HBASE-20427.master.003.patch
>
>
> According to thrift usage text:
> {code}
> -nonblocking Use the TNonblockingServer This implies the
>framed transport.
> {code}
> But the web page at port 9095 indicates {{framed = false}} when I start it
> with {{-nonblocking}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20188) [TESTING] Performance
[
https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448883#comment-16448883
]
Sean Busbey commented on HBASE-20188:
-
there's a ton of great discussion included in this jira. Could I ask y'all to
distill some of the consensus around how folks should look at simulating
application performance in the ref guide? In particular [we have this anemic
appendix on YCSB|http://hbase.apache.org/book.html#ycsb] where we could benefit
from even an explanation of the tradeoff for {{clientbuffering=true}}.
> [TESTING] Performance
> -
>
> Key: HBASE-20188
> URL: https://issues.apache.org/jira/browse/HBASE-20188
> Project: HBase
> Issue Type: Umbrella
> Components: Performance
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: CAM-CONFIG-V01.patch, HBASE-20188-xac.sh,
> HBASE-20188.sh, HBase 2.0 performance evaluation - 8GB(1).pdf, HBase 2.0
> performance evaluation - 8GB.pdf, HBase 2.0 performance evaluation - Basic vs
> None_ system settings.pdf, ITBLL2.5B_1.2.7vs2.0.0_cpu.png,
> ITBLL2.5B_1.2.7vs2.0.0_gctime.png, ITBLL2.5B_1.2.7vs2.0.0_iops.png,
> ITBLL2.5B_1.2.7vs2.0.0_load.png, ITBLL2.5B_1.2.7vs2.0.0_memheap.png,
> ITBLL2.5B_1.2.7vs2.0.0_memstore.png, ITBLL2.5B_1.2.7vs2.0.0_ops.png,
> ITBLL2.5B_1.2.7vs2.0.0_ops_NOT_summing_regions.png, YCSB_CPU.png,
> YCSB_GC_TIME.png, YCSB_IN_MEMORY_COMPACTION=NONE.ops.png, YCSB_MEMSTORE.png,
> YCSB_OPs.png, YCSB_in-memory-compaction=NONE.ops.png, YCSB_load.png,
> flamegraph-1072.1.svg, flamegraph-1072.2.svg, hbase-env.sh, hbase-site.xml,
> hbase-site.xml, hits.png, hits_with_fp_scheduler.png,
> lock.127.workloadc.20180402T200918Z.svg,
> lock.2.memsize2.c.20180403T160257Z.svg, perregion.png, run_ycsb.sh,
> total.png, tree.txt, workloadx, workloadx
>
>
> How does 2.0.0 compare to old versions? Is it faster, slower? There is rumor
> that it is much slower, that the problem is the asyncwal writing. Does
> in-memory compaction slow us down or speed us up? What happens when you
> enable offheaping?
> Keep notes here in this umbrella issue. Need to be able to say something
> about perf when 2.0.0 ships.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20478) precommit check for "hbase antipatterns" should log details and add a footer as needed
Sean Busbey created HBASE-20478: --- Summary: precommit check for "hbase antipatterns" should log details and add a footer as needed Key: HBASE-20478 URL: https://issues.apache.org/jira/browse/HBASE-20478 Project: HBase Issue Type: Improvement Components: test Reporter: Sean Busbey Assignee: Sean Busbey came up in discussion on HBASE-20332. our check of "don't do this" things in the codebase doesn't log the specifics of complaints anywhere, which forces those who want to follow up to reverse engineer the check. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (HBASE-20478) precommit check for "hbase antipatterns" should log details and add a footer as needed
[ https://issues.apache.org/jira/browse/HBASE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-20478 started by Sean Busbey. --- > precommit check for "hbase antipatterns" should log details and add a footer > as needed > -- > > Key: HBASE-20478 > URL: https://issues.apache.org/jira/browse/HBASE-20478 > Project: HBase > Issue Type: Improvement > Components: test >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Major > > came up in discussion on HBASE-20332. our check of "don't do this" things in > the codebase doesn't log the specifics of complaints anywhere, which forces > those who want to follow up to reverse engineer the check. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20478) precommit check for "hbase antipatterns" should log details and add a footer as needed
[ https://issues.apache.org/jira/browse/HBASE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-20478: Status: Patch Available (was: In Progress) > precommit check for "hbase antipatterns" should log details and add a footer > as needed > -- > > Key: HBASE-20478 > URL: https://issues.apache.org/jira/browse/HBASE-20478 > Project: HBase > Issue Type: Improvement > Components: test >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Major > Attachments: HBASE-20478.0.patch > > > came up in discussion on HBASE-20332. our check of "don't do this" things in > the codebase doesn't log the specifics of complaints anywhere, which forces > those who want to follow up to reverse engineer the check. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20478) precommit check for "hbase antipatterns" should log details and add a footer as needed
[ https://issues.apache.org/jira/browse/HBASE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-20478: Attachment: HBASE-20478.0.patch > precommit check for "hbase antipatterns" should log details and add a footer > as needed > -- > > Key: HBASE-20478 > URL: https://issues.apache.org/jira/browse/HBASE-20478 > Project: HBase > Issue Type: Improvement > Components: test >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Major > Attachments: HBASE-20478.0.patch > > > came up in discussion on HBASE-20332. our check of "don't do this" things in > the codebase doesn't log the specifics of complaints anywhere, which forces > those who want to follow up to reverse engineer the check. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20478) precommit check for "hbase antipatterns" should log details and add a footer as needed
[ https://issues.apache.org/jira/browse/HBASE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448948#comment-16448948 ] Sean Busbey commented on HBASE-20478: - -v0 - write to a log whenever we fail - if we fail at all, add a footer > precommit check for "hbase antipatterns" should log details and add a footer > as needed > -- > > Key: HBASE-20478 > URL: https://issues.apache.org/jira/browse/HBASE-20478 > Project: HBase > Issue Type: Improvement > Components: test >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Major > Attachments: HBASE-20478.0.patch > > > came up in discussion on HBASE-20332. our check of "don't do this" things in > the codebase doesn't log the specifics of complaints anywhere, which forces > those who want to follow up to reverse engineer the check. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20478) precommit check for "hbase antipatterns" should log details and add a footer as needed
[ https://issues.apache.org/jira/browse/HBASE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448949#comment-16448949 ] Hadoop QA commented on HBASE-20478: --- (!) A patch to the testing environment has been detected. Re-executing against the patched versions to perform further tests. The console is at https://builds.apache.org/job/PreCommit-HBASE-Build/12604/console in case of problems. > precommit check for "hbase antipatterns" should log details and add a footer > as needed > -- > > Key: HBASE-20478 > URL: https://issues.apache.org/jira/browse/HBASE-20478 > Project: HBase > Issue Type: Improvement > Components: test >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Major > Attachments: HBASE-20478.0.patch > > > came up in discussion on HBASE-20332. our check of "don't do this" things in > the codebase doesn't log the specifics of complaints anywhere, which forces > those who want to follow up to reverse engineer the check. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20478) precommit check for "hbase antipatterns" should log details and add a footer as needed
[
https://issues.apache.org/jira/browse/HBASE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448952#comment-16448952
]
Hadoop QA commented on HBASE-20478:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
9s{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
2s{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
12s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 0m 48s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20478 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12920349/HBASE-20478.0.patch |
| Optional Tests | asflicense shellcheck shelldocs |
| uname | Linux c03d46bb9774 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / a8be3bb814 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| 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/12604/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> precommit check for "hbase antipatterns" should log details and add a footer
> as needed
> --
>
> Key: HBASE-20478
> URL: https://issues.apache.org/jira/browse/HBASE-20478
> Project: HBase
> Issue Type: Improvement
> Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-20478.0.patch
>
>
> came up in discussion on HBASE-20332. our check of "don't do this" things in
> the codebase doesn't log the specifics of complaints anywhere, which forces
> those who want to follow up to reverse engineer the check.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20478) precommit check for "hbase antipatterns" should log details and add a footer as needed
[ https://issues.apache.org/jira/browse/HBASE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-20478: Attachment: HBASE-20478.WIP.patch > precommit check for "hbase antipatterns" should log details and add a footer > as needed > -- > > Key: HBASE-20478 > URL: https://issues.apache.org/jira/browse/HBASE-20478 > Project: HBase > Issue Type: Improvement > Components: test >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Major > Attachments: HBASE-20478.0.patch, HBASE-20478.WIP.patch > > > came up in discussion on HBASE-20332. our check of "don't do this" things in > the codebase doesn't log the specifics of complaints anywhere, which forces > those who want to follow up to reverse engineer the check. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20478) precommit check for "hbase antipatterns" should log details and add a footer as needed
[
https://issues.apache.org/jira/browse/HBASE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448954#comment-16448954
]
Sean Busbey commented on HBASE-20478:
-
-WIP
- addition of logs, same as v0 patch
- 4 WIP commits on top that break the things we check for in the
{{hbaseanti}} plugin to show the resultant footer
> precommit check for "hbase antipatterns" should log details and add a footer
> as needed
> --
>
> Key: HBASE-20478
> URL: https://issues.apache.org/jira/browse/HBASE-20478
> Project: HBase
> Issue Type: Improvement
> Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-20478.0.patch, HBASE-20478.WIP.patch
>
>
> came up in discussion on HBASE-20332. our check of "don't do this" things in
> the codebase doesn't log the specifics of complaints anywhere, which forces
> those who want to follow up to reverse engineer the check.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20332) shaded mapreduce module shouldn't include hadoop
[
https://issues.apache.org/jira/browse/HBASE-20332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448955#comment-16448955
]
Sean Busbey commented on HBASE-20332:
-
filed and put up a patch to start having a footer for hbaseanti plugin:
HBASE-20478
> shaded mapreduce module shouldn't include hadoop
>
>
> Key: HBASE-20332
> URL: https://issues.apache.org/jira/browse/HBASE-20332
> Project: HBase
> Issue Type: Sub-task
> Components: mapreduce, shading
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20332.0.patch, HBASE-20332.1.WIP.patch,
> HBASE-20332.2.WIP.patch, HBASE-20332.3.patch
>
>
> AFAICT, we should just entirely skip including hadoop in our shaded mapreduce
> module
> 1) Folks expect to run yarn / mr apps via {{hadoop jar}} / {{yarn jar}}
> 2) those commands include all the needed Hadoop jars in your classpath by
> default (both client side and in the containers)
> 3) If you try to use "user classpath first" for your job as a workaround
> (e.g. for some library your application needs that hadoop provides) then our
> inclusion of *some but not all* hadoop classes then causes everything to fall
> over because of mixing rewritten and non-rewritten hadoop classes
> 4) if you don't use "user classpath first" then all of our
> non-relocated-but-still-shaded hadoop classes are ignored anyways so we're
> just wasting space
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20478) precommit check for "hbase antipatterns" should log details and add a footer as needed
[ https://issues.apache.org/jira/browse/HBASE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448959#comment-16448959 ] Hadoop QA commented on HBASE-20478: --- (!) A patch to the testing environment has been detected. Re-executing against the patched versions to perform further tests. The console is at https://builds.apache.org/job/PreCommit-HBASE-Build/12605/console in case of problems. > precommit check for "hbase antipatterns" should log details and add a footer > as needed > -- > > Key: HBASE-20478 > URL: https://issues.apache.org/jira/browse/HBASE-20478 > Project: HBase > Issue Type: Improvement > Components: test >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Major > Attachments: HBASE-20478.0.patch, HBASE-20478.WIP.patch > > > came up in discussion on HBASE-20332. our check of "don't do this" things in > the codebase doesn't log the specifics of complaints anywhere, which forces > those who want to follow up to reverse engineer the check. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20466) Consistently use override mechanism for exempt classes in CoprocessClassloader
[
https://issues.apache.org/jira/browse/HBASE-20466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448985#comment-16448985
]
Hudson commented on HBASE-20466:
Results for branch branch-2
[build #651 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/651/]:
(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/651//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/651//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/651//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Consistently use override mechanism for exempt classes in CoprocessClassloader
> --
>
> Key: HBASE-20466
> URL: https://issues.apache.org/jira/browse/HBASE-20466
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Affects Versions: 2.0.0-beta-2, 1.4.3
>Reporter: Rich Fecher
>Assignee: Rich Fecher
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: HBASE-20466_master.patch, HBASE-20466_master_v2.patch,
> HBASE-20466_master_v3.patch
>
>
> RegionCoprocessorHost.testTableCoprocessorAttrs() use the inclusion list for
> CoprocessorClassLoader. This issue is related to HBASE-15686.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20458) Support removing a WAL from LogRoller
[ https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-20458: --- Attachment: HBASE-20458.HBASE-19064.005.patch > Support removing a WAL from LogRoller > - > > Key: HBASE-20458 > URL: https://issues.apache.org/jira/browse/HBASE-20458 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-20458.HBASE-19064.001.patch, > HBASE-20458.HBASE-19064.002.patch, HBASE-20458.HBASE-19064.003.patch, > HBASE-20458.HBASE-19064.004.patch, HBASE-20458.HBASE-19064.005.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20458) Support removing a WAL from LogRoller
[ https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16449091#comment-16449091 ] Guanghao Zhang commented on HBASE-20458: Upload a 005 patch which fixed the javadoc and checkstyle warning. > Support removing a WAL from LogRoller > - > > Key: HBASE-20458 > URL: https://issues.apache.org/jira/browse/HBASE-20458 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-20458.HBASE-19064.001.patch, > HBASE-20458.HBASE-19064.002.patch, HBASE-20458.HBASE-19064.003.patch, > HBASE-20458.HBASE-19064.004.patch, HBASE-20458.HBASE-19064.005.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[ https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20456: -- Attachment: HBASE-20456-HBASE-19064-v3.patch > Support removing a ReplicationSourceShipper for a special wal group > --- > > Key: HBASE-20456 > URL: https://issues.apache.org/jira/browse/HBASE-20456 > Project: HBase > Issue Type: Sub-task > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20456-HBASE-19064-v1.patch, > HBASE-20456-HBASE-19064-v2.patch, HBASE-20456-HBASE-19064-v3.patch, > HBASE-20456-HBASE-19064-v3.patch, HBASE-20456-HBASE-19064.patch > > > For the multi wal implementation, if a new group is created, then we will > always open a wal writer for it, even if no one uses it later. But for sync > replication, if the peer is transited to DA or S from A, the special wal will > be closed and there will be no more wal files for it so we need to close the > shipper -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20456) Support removing a ReplicationSourceShipper for a special wal group
[ https://issues.apache.org/jira/browse/HBASE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16449114#comment-16449114 ] Duo Zhang commented on HBASE-20456: --- Retry. The javac warning is not introduced by this patch. And the failed UTs are not related I suppose. > Support removing a ReplicationSourceShipper for a special wal group > --- > > Key: HBASE-20456 > URL: https://issues.apache.org/jira/browse/HBASE-20456 > Project: HBase > Issue Type: Sub-task > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20456-HBASE-19064-v1.patch, > HBASE-20456-HBASE-19064-v2.patch, HBASE-20456-HBASE-19064-v3.patch, > HBASE-20456-HBASE-19064-v3.patch, HBASE-20456-HBASE-19064.patch > > > For the multi wal implementation, if a new group is created, then we will > always open a wal writer for it, even if no one uses it later. But for sync > replication, if the peer is transited to DA or S from A, the special wal will > be closed and there will be no more wal files for it so we need to close the > shipper -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20478) precommit check for "hbase antipatterns" should log details and add a footer as needed
[
https://issues.apache.org/jira/browse/HBASE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16449127#comment-16449127
]
Hadoop QA commented on HBASE-20478:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
2s{color} | {color:blue} Shelldocs was not available. {color} |
| {color:red}-1{color} | {color:red} hbaseanti {color} | {color:red} 0m
0s{color} | {color:red} The patch appears to have anti-pattern where
BYTES_COMPARATOR was omitted. {color} |
| {color:red}-1{color} | {color:red} hbaseanti {color} | {color:red} 0m
0s{color} | {color:red} The patch appears use Hadoop classification instead of
HBase. {color} |
| {color:red}-1{color} | {color:red} hbaseanti {color} | {color:red} 0m
0s{color} | {color:red} The patch appears use Jackson 1 classes/annotations.
{color} |
| {color:red}-1{color} | {color:red} hbaseanti {color} | {color:red} 0m
0s{color} | {color:red} The patch appears to use commons-logging instead of
slf4j. {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
22s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
23s{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
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
50s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
12s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 2m
27s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 3m
20s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 3m 20s{color}
| {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
16s{color} | {color:red} hbase-mapreduce: The patch generated 1 new + 30
unchanged - 0 fixed = 31 total (was 30) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
10s{color} | {color:red} hbase-backup: The patch generated 2 new + 1 unchanged
- 0 fixed = 3 total (was 1) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 2m
7s{color} | {color:red} root: The patch generated 3 new + 31 unchanged - 0
fixed = 34 total (was 31) {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:red}-1{color} | {color:red} shadedjars {color} | {color:red} 3m
25s{color} | {color:red} patch has 40 errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
45s{color} | {color:red} The patch causes 40 errors with Hadoop v2.6.5. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m
32s{color} | {color:red} The patch causes 40 errors with Hadoop v2.7.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m
29s{color} | {color:red} The patch causes 40 er
[jira] [Updated] (HBASE-20468) RPC quota requests ineffective due to not counting multi-actions
[ https://issues.apache.org/jira/browse/HBASE-20468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-20468: --- Status: Patch Available (was: In Progress) > RPC quota requests ineffective due to not counting multi-actions > > > Key: HBASE-20468 > URL: https://issues.apache.org/jira/browse/HBASE-20468 > Project: HBase > Issue Type: Bug > Components: rpc >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: 2.1.0, 1.5.0, 1.3.3, 1.2.8, 2.0.1, 1.4.5 > > Attachments: HBASE-20468.001.patch > > > Was digging into a problem with [~ankit.singhal] where setting RPC quotas on > number of requests wasn't having any effect on a multi-Get > Ankit did enough digging to find that this was because each RPC was being > treated as one request instead of the number of requests contained within the > RPC itself. > Thinking as an operator, this is a pretty ineffective control because a user > could just craft their API usage easily to work around any kind of limits I > want to set to control their impact on the system. TimeBasedLimiter is > assuming that one call to the quota code can only count as one request which > I think is just wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20468) RPC quota requests ineffective due to not counting multi-actions
[ https://issues.apache.org/jira/browse/HBASE-20468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-20468: --- Attachment: HBASE-20468.001.patch > RPC quota requests ineffective due to not counting multi-actions > > > Key: HBASE-20468 > URL: https://issues.apache.org/jira/browse/HBASE-20468 > Project: HBase > Issue Type: Bug > Components: rpc >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: 2.1.0, 1.5.0, 1.3.3, 1.2.8, 2.0.1, 1.4.5 > > Attachments: HBASE-20468.001.patch > > > Was digging into a problem with [~ankit.singhal] where setting RPC quotas on > number of requests wasn't having any effect on a multi-Get > Ankit did enough digging to find that this was because each RPC was being > treated as one request instead of the number of requests contained within the > RPC itself. > Thinking as an operator, this is a pretty ineffective control because a user > could just craft their API usage easily to work around any kind of limits I > want to set to control their impact on the system. TimeBasedLimiter is > assuming that one call to the quota code can only count as one request which > I think is just wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20468) RPC quota requests ineffective due to not counting multi-actions
[
https://issues.apache.org/jira/browse/HBASE-20468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16449138#comment-16449138
]
Hadoop QA commented on HBASE-20468:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s{color}
| {color:red} HBASE-20468 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.7.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-20468 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12920382/HBASE-20468.001.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12608/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> RPC quota requests ineffective due to not counting multi-actions
>
>
> Key: HBASE-20468
> URL: https://issues.apache.org/jira/browse/HBASE-20468
> Project: HBase
> Issue Type: Bug
> Components: rpc
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Critical
> Fix For: 2.1.0, 1.5.0, 1.3.3, 1.2.8, 2.0.1, 1.4.5
>
> Attachments: HBASE-20468.001.patch
>
>
> Was digging into a problem with [~ankit.singhal] where setting RPC quotas on
> number of requests wasn't having any effect on a multi-Get
> Ankit did enough digging to find that this was because each RPC was being
> treated as one request instead of the number of requests contained within the
> RPC itself.
> Thinking as an operator, this is a pretty ineffective control because a user
> could just craft their API usage easily to work around any kind of limits I
> want to set to control their impact on the system. TimeBasedLimiter is
> assuming that one call to the quota code can only count as one request which
> I think is just wrong.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20468) RPC quota requests ineffective due to not counting multi-actions
[ https://issues.apache.org/jira/browse/HBASE-20468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-20468: --- Resolution: Duplicate Fix Version/s: (was: 1.4.5) (was: 2.0.1) (was: 1.2.8) (was: 1.3.3) (was: 1.5.0) (was: 2.1.0) Status: Resolved (was: Patch Available) Duplicate of HBASE-19924 > RPC quota requests ineffective due to not counting multi-actions > > > Key: HBASE-20468 > URL: https://issues.apache.org/jira/browse/HBASE-20468 > Project: HBase > Issue Type: Bug > Components: rpc >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Attachments: HBASE-20468.001.patch > > > Was digging into a problem with [~ankit.singhal] where setting RPC quotas on > number of requests wasn't having any effect on a multi-Get > Ankit did enough digging to find that this was because each RPC was being > treated as one request instead of the number of requests contained within the > RPC itself. > Thinking as an operator, this is a pretty ineffective control because a user > could just craft their API usage easily to work around any kind of limits I > want to set to control their impact on the system. TimeBasedLimiter is > assuming that one call to the quota code can only count as one request which > I think is just wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19924) hbase rpc throttling does not work for multi() with request count rater.
[
https://issues.apache.org/jira/browse/HBASE-19924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16449146#comment-16449146
]
Josh Elser commented on HBASE-19924:
[~huaxiang], what about landing this on other branch-1 versions? I've been
tracking the same problem in HBASE-20468, but only noticed your fix here
landing after I was ready to put up a patch :)
> hbase rpc throttling does not work for multi() with request count rater.
>
>
> Key: HBASE-19924
> URL: https://issues.apache.org/jira/browse/HBASE-19924
> Project: HBase
> Issue Type: Bug
> Components: rpc
>Affects Versions: 0.16.0, 1.2.6
>Reporter: huaxiang sun
>Assignee: huaxiang sun
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-19924-master-v001.patch,
> HBASE-19924-master-v002.patch, HBASE-19924-master-v002.patch,
> HBASE-19924-master-v002.patch, HBASE-19924-master-v002.patch
>
>
> Basically, rpc throttling does not work for request count based rater for
> multi. for the following code, when it calls limiter's checkQuota(),
> numWrites/numReads is lost.
> {code:java}
> @Override
> public void checkQuota(int numWrites, int numReads, int numScans) throws
> ThrottlingException {
> writeConsumed = estimateConsume(OperationType.MUTATE, numWrites, 100);
> readConsumed = estimateConsume(OperationType.GET, numReads, 100);
> readConsumed += estimateConsume(OperationType.SCAN, numScans, 1000);
> writeAvailable = Long.MAX_VALUE;
> readAvailable = Long.MAX_VALUE;
> for (final QuotaLimiter limiter : limiters) {
> if (limiter.isBypass()) continue;
> limiter.checkQuota(writeConsumed, readConsumed);
> readAvailable = Math.min(readAvailable, limiter.getReadAvailable());
> writeAvailable = Math.min(writeAvailable, limiter.getWriteAvailable());
> }
> for (final QuotaLimiter limiter : limiters) {
> limiter.grabQuota(writeConsumed, readConsumed);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20447) Only fail cacheBlock if block collisions aren't related to next block metadata
[ https://issues.apache.org/jira/browse/HBASE-20447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zach York updated HBASE-20447: -- Attachment: HBASE-20447.branch-1.002.patch > Only fail cacheBlock if block collisions aren't related to next block metadata > -- > > Key: HBASE-20447 > URL: https://issues.apache.org/jira/browse/HBASE-20447 > Project: HBase > Issue Type: Bug > Components: BlockCache, BucketCache >Affects Versions: 1.4.3, 2.0.0 >Reporter: Zach York >Assignee: Zach York >Priority: Major > Fix For: 3.0.0, 2.1.0, 1.5.0, 2.0.1, 1.4.5 > > Attachments: HBASE-20447.branch-1.001.patch, > HBASE-20447.branch-1.002.patch, HBASE-20447.master.001.patch > > > This is the issue I was originally having here: > [http://mail-archives.apache.org/mod_mbox/hbase-dev/201802.mbox/%3CCAN+qs_Pav=md_aoj4xji+kcnetubg2xou2ntxv1g6m8-5vn...@mail.gmail.com%3E] > > When we pread, we don't force the read to read all of the next block header. > However, when we get into a race condition where two opener threads try to > cache the same block and one thread read all of the next block header and the > other one didn't, it will fail the open process. This is especially important > in a splitting case where it will potentially fail the split process. > Instead, in the caches, we should only fail if the required blocks are > different. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20447) Only fail cacheBlock if block collisions aren't related to next block metadata
[ https://issues.apache.org/jira/browse/HBASE-20447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16449162#comment-16449162 ] Zach York commented on HBASE-20447: --- Added a patch incorporating [~apurtell] and [~yuzhih...@gmail.com] 's comments. [~anoop.hbase] Yes this is what I did to make this pass consistently in branch-1, but that isn't working for the master branch patch (with some additional modifications, I needed to release the object first). > Only fail cacheBlock if block collisions aren't related to next block metadata > -- > > Key: HBASE-20447 > URL: https://issues.apache.org/jira/browse/HBASE-20447 > Project: HBase > Issue Type: Bug > Components: BlockCache, BucketCache >Affects Versions: 1.4.3, 2.0.0 >Reporter: Zach York >Assignee: Zach York >Priority: Major > Fix For: 3.0.0, 2.1.0, 1.5.0, 2.0.1, 1.4.5 > > Attachments: HBASE-20447.branch-1.001.patch, > HBASE-20447.branch-1.002.patch, HBASE-20447.master.001.patch > > > This is the issue I was originally having here: > [http://mail-archives.apache.org/mod_mbox/hbase-dev/201802.mbox/%3CCAN+qs_Pav=md_aoj4xji+kcnetubg2xou2ntxv1g6m8-5vn...@mail.gmail.com%3E] > > When we pread, we don't force the read to read all of the next block header. > However, when we get into a race condition where two opener threads try to > cache the same block and one thread read all of the next block header and the > other one didn't, it will fail the open process. This is especially important > in a splitting case where it will potentially fail the split process. > Instead, in the caches, we should only fail if the required blocks are > different. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20458) Support removing a WAL from LogRoller
[ https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-20458: --- Attachment: HBASE-20458.HBASE-19064.006.patch > Support removing a WAL from LogRoller > - > > Key: HBASE-20458 > URL: https://issues.apache.org/jira/browse/HBASE-20458 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-20458.HBASE-19064.001.patch, > HBASE-20458.HBASE-19064.002.patch, HBASE-20458.HBASE-19064.003.patch, > HBASE-20458.HBASE-19064.004.patch, HBASE-20458.HBASE-19064.005.patch, > HBASE-20458.HBASE-19064.006.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20425) Do not write the cluster id of the current active cluster when writing remote WAL
[ https://issues.apache.org/jira/browse/HBASE-20425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-20425: - Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to branch HBASE-19064, Thanks [~Apache9] for reviewing. > Do not write the cluster id of the current active cluster when writing remote > WAL > - > > Key: HBASE-20425 > URL: https://issues.apache.org/jira/browse/HBASE-20425 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-20425.HBASE-19064.v1.patch > > > The wal entries which are replayed when converting a cluster from S to DA > need to be replicated back to the old A cluster. if we write the cluster id > of A into the wal entries, we will skip replicating them... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19924) hbase rpc throttling does not work for multi() with request count rater.
[
https://issues.apache.org/jira/browse/HBASE-19924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16449184#comment-16449184
]
Andrew Purtell commented on HBASE-19924:
Dang missed this one. Branch-1 could really use this. We could use HBASE-20468
for backport? Unless the patch will apply without too much trouble.
> hbase rpc throttling does not work for multi() with request count rater.
>
>
> Key: HBASE-19924
> URL: https://issues.apache.org/jira/browse/HBASE-19924
> Project: HBase
> Issue Type: Bug
> Components: rpc
>Affects Versions: 0.16.0, 1.2.6
>Reporter: huaxiang sun
>Assignee: huaxiang sun
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-19924-master-v001.patch,
> HBASE-19924-master-v002.patch, HBASE-19924-master-v002.patch,
> HBASE-19924-master-v002.patch, HBASE-19924-master-v002.patch
>
>
> Basically, rpc throttling does not work for request count based rater for
> multi. for the following code, when it calls limiter's checkQuota(),
> numWrites/numReads is lost.
> {code:java}
> @Override
> public void checkQuota(int numWrites, int numReads, int numScans) throws
> ThrottlingException {
> writeConsumed = estimateConsume(OperationType.MUTATE, numWrites, 100);
> readConsumed = estimateConsume(OperationType.GET, numReads, 100);
> readConsumed += estimateConsume(OperationType.SCAN, numScans, 1000);
> writeAvailable = Long.MAX_VALUE;
> readAvailable = Long.MAX_VALUE;
> for (final QuotaLimiter limiter : limiters) {
> if (limiter.isBypass()) continue;
> limiter.checkQuota(writeConsumed, readConsumed);
> readAvailable = Math.min(readAvailable, limiter.getReadAvailable());
> writeAvailable = Math.min(writeAvailable, limiter.getWriteAvailable());
> }
> for (final QuotaLimiter limiter : limiters) {
> limiter.grabQuota(writeConsumed, readConsumed);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20458) Support removing a WAL from LogRoller
[ https://issues.apache.org/jira/browse/HBASE-20458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-20458: --- Attachment: HBASE-20458.HBASE-19064.007.patch > Support removing a WAL from LogRoller > - > > Key: HBASE-20458 > URL: https://issues.apache.org/jira/browse/HBASE-20458 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-20458.HBASE-19064.001.patch, > HBASE-20458.HBASE-19064.002.patch, HBASE-20458.HBASE-19064.003.patch, > HBASE-20458.HBASE-19064.004.patch, HBASE-20458.HBASE-19064.005.patch, > HBASE-20458.HBASE-19064.006.patch, HBASE-20458.HBASE-19064.007.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20447) Only fail cacheBlock if block collisions aren't related to next block metadata
[
https://issues.apache.org/jira/browse/HBASE-20447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16449200#comment-16449200
]
Hadoop QA commented on HBASE-20447:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
27s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
1s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 6 new or modified test
files. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
40s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
14s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
13s{color} | {color:green} branch-1 passed with JDK v1.8.0_163 {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
19s{color} | {color:red} hbase-server in branch-1 failed with JDK v1.7.0_171.
{color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
13s{color} | {color:red} hbase-external-blockcache in branch-1 failed with JDK
v1.7.0_171. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
40s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
52s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
45s{color} | {color:green} branch-1 passed with JDK v1.8.0_163 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
54s{color} | {color:green} branch-1 passed with JDK v1.7.0_171 {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} 1m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
2s{color} | {color:green} the patch passed with JDK v1.8.0_163 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
2s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
21s{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_171.
{color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
14s{color} | {color:red} hbase-external-blockcache in the patch failed with JDK
v1.7.0_171. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 21s{color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_171. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 14s{color}
| {color:red} hbase-external-blockcache in the patch failed with JDK
v1.7.0_171. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
23s{color} | {color:red} hbase-server: The patch generated 16 new + 206
unchanged - 1 fixed = 222 total (was 207) {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} 2m
54s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
34s{color} | {color:red} The patch causes 44 errors with Hadoop v2.4.1. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m
11s{color} | {color:red} The patch causes 44 errors with Hadoop v2.5.2. {color}
|
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
36s{color} | {color:red} hbase-server-jdk1.8.0_163 with JDK v1.8.0_163
generated 1 new + 3 unchanged - 0 fixed = 4 total (was 3) {color} |
| {color:red}-1{color} | {co
[jira] [Updated] (HBASE-20434) Also remove remote wals when peer is in DA state
[ https://issues.apache.org/jira/browse/HBASE-20434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20434: -- Summary: Also remove remote wals when peer is in DA state (was: Support removing all the remote wals for a sync replication peer in S state) > Also remove remote wals when peer is in DA state > > > Key: HBASE-20434 > URL: https://issues.apache.org/jira/browse/HBASE-20434 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Priority: Major > > Consider we have two clusters in A and S state, and then we transit A to DA. > And later we want to transit DA to A, since the remote cluster is in S, we > should be able to do it. But there are some remote wals on the HDFS for the > cluster in S state, so we need to remove them first before transiting the > cluster in DA state to A. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20434) Also remove remote wals when peer is in DA state
[ https://issues.apache.org/jira/browse/HBASE-20434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16449203#comment-16449203 ] Duo Zhang commented on HBASE-20434: --- Talked with [~zghaobac] offline, a better way is always remove the remote wal when the wal name is for a sync replication peer, no matter whether it is in A or DA. Add we need to add UTs to confirm it. > Also remove remote wals when peer is in DA state > > > Key: HBASE-20434 > URL: https://issues.apache.org/jira/browse/HBASE-20434 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Priority: Major > > Consider we have two clusters in A and S state, and then we transit A to DA. > And later we want to transit DA to A, since the remote cluster is in S, we > should be able to do it. But there are some remote wals on the HDFS for the > cluster in S state, so we need to remove them first before transiting the > cluster in DA state to A. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20316) Backport HBASE-20229 "ConnectionImplementation.locateRegions() returns duplicated entries when region replication is on" to branch-1
[ https://issues.apache.org/jira/browse/HBASE-20316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16449204#comment-16449204 ] Toshihiro Suzuki commented on HBASE-20316: -- Thank you for reviewing [~huaxiang]. > Backport HBASE-20229 "ConnectionImplementation.locateRegions() returns > duplicated entries when region replication is on" to branch-1 > > > Key: HBASE-20316 > URL: https://issues.apache.org/jira/browse/HBASE-20316 > Project: HBase > Issue Type: Sub-task > Components: backport >Reporter: stack >Assignee: Toshihiro Suzuki >Priority: Major > Attachments: HBASE-20229.branch-1.002.patch, > HBASE-20229.branch-1.002.patch, HBASE-20229.branch-1.002.patch, > HBASE-20229.branch-1.002.patch > > > Issue to backport parent to branch-1. Hope you don't mind my assigning it to > you [~brfrn169] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
