[jira] [Commented] (HBASE-21312) ReplicationSource should log the incorrect peerClusterId at Error level instead of Info
[
https://issues.apache.org/jira/browse/HBASE-21312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859358#comment-16859358
]
HBase QA commented on HBASE-21312:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
39s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
37s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
43s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
52s{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 + 4 unchanged
- 6 fixed = 5 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
38s{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 14s{color} | {color:green} Patch does not cause any errors with Hadoop
2.8.5 2.9.2 or 3.1.2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
36s{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}214m
45s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
25s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}264m 18s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base:
https://builds.apache.org/job/PreCommit-HBASE-Build/506/artifact/patchprocess/Dockerfile
|
| JIRA Issue | HBASE-21312 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12959361/HBASE-21312-master-002.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 05732f286b79 4.4.0-143-generic #169~14.04.2-Ubuntu SMP Wed Feb
13 15:00:41 UTC 2019 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / b32e716bee |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.11 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/506/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/506/testReport/ |
| Max. process+thread count | 4935 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
[jira] [Commented] (HBASE-21312) ReplicationSource should log the incorrect peerClusterId at Error level instead of Info
[
https://issues.apache.org/jira/browse/HBASE-21312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859340#comment-16859340
]
Wellington Chevreuil commented on HBASE-21312:
--
Hi [~lingesh],
Thanks for the contribution! Some observations on this v2 patch:
1) It seems that the added test is not enforcing the new behaviour, had run it
against the original version of ReplicationSource that doesn't pass
ReplicationException to _terminate_ method, and the test still passed. I think
the problem is because it's only asserting the condition when the message is in
the log (line #394), but when we don't log the message, the test never enter
the _if_ statement from line #392, and never calls any further _assert_, which
then makes it complete successful.
2) Noticed you had fixed some pre-existing checkstyles issues. For better
tracking purposes, we should ideally address those on specific jiras for
checkstyles issues, leaving this patch only with changes relevant for this Jira
purpose.
3) Noticed this latest patch has been created from a _diff_ command. While this
is ok for reporting all the changes properly, _git_ provides _format-patch_
command, that will insert additional info about the author and commit message,
along with the diff itself. Useful info on how to format/create patches is
available
[here|[https://hbase.apache.org/book.html#submitting.patches.create]].
> ReplicationSource should log the incorrect peerClusterId at Error level
> instead of Info
> ---
>
> Key: HBASE-21312
> URL: https://issues.apache.org/jira/browse/HBASE-21312
> Project: HBase
> Issue Type: Improvement
> Components: Replication
>Affects Versions: 2.0.2, 1.4.7
>Reporter: Lingeshwaran Radhakrishnan
>Assignee: Lingeshwaran Radhakrishnan
>Priority: Minor
> Labels: supportability
> Attachments: HBASE-21312-master-001.patch,
> HBASE-21312-master-002.patch
>
>
> Normally, Replication needs peer cluster ID to be different from the source.
> However, if target carries the same cluster ID as source, then during the
> ReplicationSource initialization process, following is reported in the
> RegionServer logs before terminating the ReplicationSource thread.
> {code:java}
> 2018-10-08 10:19:09,155 INFO
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Closing
> source 1 because: ClusterId 67318852-e2b7-47a7-a303-f1722cb61a06 is
> replicating to itself: peerClusterId 67318852-e2b7-47a7-a303-f1722cb61a06
> which is not allowed by
> ReplicationEndpoint:org.apache.hadoop.hbase.replication.regionserver.HBaseInterClusterReplicationEndpoint{code}
> Here is the related code snippet which does this in the ReplicationSource
> class
> {code:java}
> // In rare case, zookeeper setting may be messed up. That leads to the
> incorrect
> // peerClusterId value, which is the same as the source clusterId
> if (clusterId.equals(peerClusterId) &&
> !replicationEndpoint.canReplicateToSameCluster()) {
> this.terminate("ClusterId " + clusterId + " is replicating to itself:
> peerClusterId "
> + peerClusterId + " which is not allowed by ReplicationEndpoint:"
> + replicationEndpoint.getClass().getName(), null, false);
> this.manager.removeSource(this);
> return;
> }{code}
> It would be good to have this logged at ERROR level instead of INFO for the
> following reasons
> 1. Under normal situation/case, the Peer Cluster ID would be different
> 2. It would help to easily troubleshoot issues that arises due to matching
> replication Peer cluster ID
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21312) ReplicationSource should log the incorrect peerClusterId at Error level instead of Info
[
https://issues.apache.org/jira/browse/HBASE-21312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772682#comment-16772682
]
Hadoop QA commented on HBASE-21312:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
2s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
22s{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
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
39s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
4s{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:green}+1{color} | {color:green} javac {color} | {color:green} 1m
48s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
2s{color} | {color:red} hbase-server: The patch generated 1 new + 4 unchanged -
6 fixed = 5 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}
8m 46s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}133m
0s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
31s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}174m 15s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21312 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12959361/HBASE-21312-master-002.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux faac49c967bc 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / e257f4698c |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/16046/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/16046/testReport/ |
| Max. process+thread count | 6132 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
[jira] [Commented] (HBASE-21312) ReplicationSource should log the incorrect peerClusterId at Error level instead of Info
[
https://issues.apache.org/jira/browse/HBASE-21312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772593#comment-16772593
]
Lingeshwaran Radhakrishnan commented on HBASE-21312:
Thank you [~daisuke.kobayashi]
> ReplicationSource should log the incorrect peerClusterId at Error level
> instead of Info
> ---
>
> Key: HBASE-21312
> URL: https://issues.apache.org/jira/browse/HBASE-21312
> Project: HBase
> Issue Type: Improvement
> Components: Replication
>Affects Versions: 2.0.2, 1.4.7
>Reporter: Lingeshwaran Radhakrishnan
>Assignee: Lingeshwaran Radhakrishnan
>Priority: Minor
> Labels: supportability
> Attachments: HBASE-21312-master-001.patch,
> HBASE-21312-master-002.patch
>
>
> Normally, Replication needs peer cluster ID to be different from the source.
> However, if target carries the same cluster ID as source, then during the
> ReplicationSource initialization process, following is reported in the
> RegionServer logs before terminating the ReplicationSource thread.
> {code:java}
> 2018-10-08 10:19:09,155 INFO
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Closing
> source 1 because: ClusterId 67318852-e2b7-47a7-a303-f1722cb61a06 is
> replicating to itself: peerClusterId 67318852-e2b7-47a7-a303-f1722cb61a06
> which is not allowed by
> ReplicationEndpoint:org.apache.hadoop.hbase.replication.regionserver.HBaseInterClusterReplicationEndpoint{code}
> Here is the related code snippet which does this in the ReplicationSource
> class
> {code:java}
> // In rare case, zookeeper setting may be messed up. That leads to the
> incorrect
> // peerClusterId value, which is the same as the source clusterId
> if (clusterId.equals(peerClusterId) &&
> !replicationEndpoint.canReplicateToSameCluster()) {
> this.terminate("ClusterId " + clusterId + " is replicating to itself:
> peerClusterId "
> + peerClusterId + " which is not allowed by ReplicationEndpoint:"
> + replicationEndpoint.getClass().getName(), null, false);
> this.manager.removeSource(this);
> return;
> }{code}
> It would be good to have this logged at ERROR level instead of INFO for the
> following reasons
> 1. Under normal situation/case, the Peer Cluster ID would be different
> 2. It would help to easily troubleshoot issues that arises due to matching
> replication Peer cluster ID
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21312) ReplicationSource should log the incorrect peerClusterId at Error level instead of Info
[
https://issues.apache.org/jira/browse/HBASE-21312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772499#comment-16772499
]
Daisuke Kobayashi commented on HBASE-21312:
---
With help from [~brfrn169], the contributor role gets added to [~lingesh] and I
have assigned you as the owner. Can you confirm if you could submit the patch
again?
> ReplicationSource should log the incorrect peerClusterId at Error level
> instead of Info
> ---
>
> Key: HBASE-21312
> URL: https://issues.apache.org/jira/browse/HBASE-21312
> Project: HBase
> Issue Type: Improvement
> Components: Replication
>Affects Versions: 2.0.2, 1.4.7
>Reporter: Lingeshwaran Radhakrishnan
>Assignee: Lingeshwaran Radhakrishnan
>Priority: Minor
> Attachments: HBASE-21312-master-001.patch,
> HBASE-21312-master-002.patch
>
>
> Normally, Replication needs peer cluster ID to be different from the source.
> However, if target carries the same cluster ID as source, then during the
> ReplicationSource initialization process, following is reported in the
> RegionServer logs before terminating the ReplicationSource thread.
> {code:java}
> 2018-10-08 10:19:09,155 INFO
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Closing
> source 1 because: ClusterId 67318852-e2b7-47a7-a303-f1722cb61a06 is
> replicating to itself: peerClusterId 67318852-e2b7-47a7-a303-f1722cb61a06
> which is not allowed by
> ReplicationEndpoint:org.apache.hadoop.hbase.replication.regionserver.HBaseInterClusterReplicationEndpoint{code}
> Here is the related code snippet which does this in the ReplicationSource
> class
> {code:java}
> // In rare case, zookeeper setting may be messed up. That leads to the
> incorrect
> // peerClusterId value, which is the same as the source clusterId
> if (clusterId.equals(peerClusterId) &&
> !replicationEndpoint.canReplicateToSameCluster()) {
> this.terminate("ClusterId " + clusterId + " is replicating to itself:
> peerClusterId "
> + peerClusterId + " which is not allowed by ReplicationEndpoint:"
> + replicationEndpoint.getClass().getName(), null, false);
> this.manager.removeSource(this);
> return;
> }{code}
> It would be good to have this logged at ERROR level instead of INFO for the
> following reasons
> 1. Under normal situation/case, the Peer Cluster ID would be different
> 2. It would help to easily troubleshoot issues that arises due to matching
> replication Peer cluster ID
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21312) ReplicationSource should log the incorrect peerClusterId at Error level instead of Info
[
https://issues.apache.org/jira/browse/HBASE-21312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771540#comment-16771540
]
Lingeshwaran Radhakrishnan commented on HBASE-21312:
I am unable to change the status of the Jira to Patch Available, maybe I am not
the Assignee yet?. Can you assign this Jira to me?
> ReplicationSource should log the incorrect peerClusterId at Error level
> instead of Info
> ---
>
> Key: HBASE-21312
> URL: https://issues.apache.org/jira/browse/HBASE-21312
> Project: HBase
> Issue Type: Improvement
> Components: Replication
>Affects Versions: 2.0.2, 1.4.7
>Reporter: Lingeshwaran Radhakrishnan
>Priority: Minor
> Attachments: HBASE-21312-master-001.patch,
> HBASE-21312-master-002.patch
>
>
> Normally, Replication needs peer cluster ID to be different from the source.
> However, if target carries the same cluster ID as source, then during the
> ReplicationSource initialization process, following is reported in the
> RegionServer logs before terminating the ReplicationSource thread.
> {code:java}
> 2018-10-08 10:19:09,155 INFO
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Closing
> source 1 because: ClusterId 67318852-e2b7-47a7-a303-f1722cb61a06 is
> replicating to itself: peerClusterId 67318852-e2b7-47a7-a303-f1722cb61a06
> which is not allowed by
> ReplicationEndpoint:org.apache.hadoop.hbase.replication.regionserver.HBaseInterClusterReplicationEndpoint{code}
> Here is the related code snippet which does this in the ReplicationSource
> class
> {code:java}
> // In rare case, zookeeper setting may be messed up. That leads to the
> incorrect
> // peerClusterId value, which is the same as the source clusterId
> if (clusterId.equals(peerClusterId) &&
> !replicationEndpoint.canReplicateToSameCluster()) {
> this.terminate("ClusterId " + clusterId + " is replicating to itself:
> peerClusterId "
> + peerClusterId + " which is not allowed by ReplicationEndpoint:"
> + replicationEndpoint.getClass().getName(), null, false);
> this.manager.removeSource(this);
> return;
> }{code}
> It would be good to have this logged at ERROR level instead of INFO for the
> following reasons
> 1. Under normal situation/case, the Peer Cluster ID would be different
> 2. It would help to easily troubleshoot issues that arises due to matching
> replication Peer cluster ID
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21312) ReplicationSource should log the incorrect peerClusterId at Error level instead of Info
[
https://issues.apache.org/jira/browse/HBASE-21312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770982#comment-16770982
]
Lingeshwaran Radhakrishnan commented on HBASE-21312:
[~yuzhih...@gmail.com]
Thank you for your comment. It was by mistake and I have corrected it in the
updated/revised V2 patch posted. I have also addressed the Unit test and
Checkstyle failures reported. Please have a look and let me know in case of any
further feedback.
> ReplicationSource should log the incorrect peerClusterId at Error level
> instead of Info
> ---
>
> Key: HBASE-21312
> URL: https://issues.apache.org/jira/browse/HBASE-21312
> Project: HBase
> Issue Type: Improvement
> Components: Replication
>Affects Versions: 2.0.2, 1.4.7
>Reporter: Lingeshwaran Radhakrishnan
>Priority: Minor
> Attachments: HBASE-21312-master-001.patch
>
>
> Normally, Replication needs peer cluster ID to be different from the source.
> However, if target carries the same cluster ID as source, then during the
> ReplicationSource initialization process, following is reported in the
> RegionServer logs before terminating the ReplicationSource thread.
> {code:java}
> 2018-10-08 10:19:09,155 INFO
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Closing
> source 1 because: ClusterId 67318852-e2b7-47a7-a303-f1722cb61a06 is
> replicating to itself: peerClusterId 67318852-e2b7-47a7-a303-f1722cb61a06
> which is not allowed by
> ReplicationEndpoint:org.apache.hadoop.hbase.replication.regionserver.HBaseInterClusterReplicationEndpoint{code}
> Here is the related code snippet which does this in the ReplicationSource
> class
> {code:java}
> // In rare case, zookeeper setting may be messed up. That leads to the
> incorrect
> // peerClusterId value, which is the same as the source clusterId
> if (clusterId.equals(peerClusterId) &&
> !replicationEndpoint.canReplicateToSameCluster()) {
> this.terminate("ClusterId " + clusterId + " is replicating to itself:
> peerClusterId "
> + peerClusterId + " which is not allowed by ReplicationEndpoint:"
> + replicationEndpoint.getClass().getName(), null, false);
> this.manager.removeSource(this);
> return;
> }{code}
> It would be good to have this logged at ERROR level instead of INFO for the
> following reasons
> 1. Under normal situation/case, the Peer Cluster ID would be different
> 2. It would help to easily troubleshoot issues that arises due to matching
> replication Peer cluster ID
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21312) ReplicationSource should log the incorrect peerClusterId at Error level instead of Info
[
https://issues.apache.org/jira/browse/HBASE-21312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649416#comment-16649416
]
Hadoop QA commented on HBASE-21312:
---
| (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:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
57s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
11s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
14s{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
59s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
57s{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
14s{color} | {color:red} hbase-server: The patch generated 8 new + 10 unchanged
- 0 fixed = 18 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
38s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
10m 53s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}115m 4s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
31s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}158m 14s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.replication.regionserver.TestReplicationSource |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21312 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12943839/HBASE-21312-master-001.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux fb30159138f5 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27
10:45:36 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 | master / dde336f6ef |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/14691/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| unit |
[jira] [Commented] (HBASE-21312) ReplicationSource should log the incorrect peerClusterId at Error level instead of Info
[
https://issues.apache.org/jira/browse/HBASE-21312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649390#comment-16649390
]
Ted Yu commented on HBASE-21312:
{code}
407 tearDownAfterClass();
{code}
Why is the method called at the end of the test ?
{code}
@AfterClass
public static void tearDownAfterClass() throws Exception {
{code}
> ReplicationSource should log the incorrect peerClusterId at Error level
> instead of Info
> ---
>
> Key: HBASE-21312
> URL: https://issues.apache.org/jira/browse/HBASE-21312
> Project: HBase
> Issue Type: Improvement
> Components: Replication
>Affects Versions: 2.0.2, 1.4.7
>Reporter: Lingeshwaran Radhakrishnan
>Priority: Minor
> Attachments: HBASE-21312-master-001.patch
>
>
> Normally, Replication needs peer cluster ID to be different from the source.
> However, if target carries the same cluster ID as source, then during the
> ReplicationSource initialization process, following is reported in the
> RegionServer logs before terminating the ReplicationSource thread.
> {code:java}
> 2018-10-08 10:19:09,155 INFO
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Closing
> source 1 because: ClusterId 67318852-e2b7-47a7-a303-f1722cb61a06 is
> replicating to itself: peerClusterId 67318852-e2b7-47a7-a303-f1722cb61a06
> which is not allowed by
> ReplicationEndpoint:org.apache.hadoop.hbase.replication.regionserver.HBaseInterClusterReplicationEndpoint{code}
> Here is the related code snippet which does this in the ReplicationSource
> class
> {code:java}
> // In rare case, zookeeper setting may be messed up. That leads to the
> incorrect
> // peerClusterId value, which is the same as the source clusterId
> if (clusterId.equals(peerClusterId) &&
> !replicationEndpoint.canReplicateToSameCluster()) {
> this.terminate("ClusterId " + clusterId + " is replicating to itself:
> peerClusterId "
> + peerClusterId + " which is not allowed by ReplicationEndpoint:"
> + replicationEndpoint.getClass().getName(), null, false);
> this.manager.removeSource(this);
> return;
> }{code}
> It would be good to have this logged at ERROR level instead of INFO for the
> following reasons
> 1. Under normal situation/case, the Peer Cluster ID would be different
> 2. It would help to easily troubleshoot issues that arises due to matching
> replication Peer cluster ID
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21312) ReplicationSource should log the incorrect peerClusterId at Error level instead of Info
[
https://issues.apache.org/jira/browse/HBASE-21312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649356#comment-16649356
]
Lingeshwaran Radhakrishnan commented on HBASE-21312:
I am interested to work on this. Attached an initial version of the patch. Let
me know if there is anything to improve the patch.
> ReplicationSource should log the incorrect peerClusterId at Error level
> instead of Info
> ---
>
> Key: HBASE-21312
> URL: https://issues.apache.org/jira/browse/HBASE-21312
> Project: HBase
> Issue Type: Improvement
> Components: Replication
>Affects Versions: 2.0.2, 1.4.7
>Reporter: Lingeshwaran Radhakrishnan
>Priority: Minor
> Attachments: HBASE-21312-master-001.patch
>
>
> Normally, Replication needs peer cluster ID to be different from the source.
> However, if target carries the same cluster ID as source, then during the
> ReplicationSource initialization process, following is reported in the
> RegionServer logs before terminating the ReplicationSource thread.
> {code:java}
> 2018-10-08 10:19:09,155 INFO
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Closing
> source 1 because: ClusterId 67318852-e2b7-47a7-a303-f1722cb61a06 is
> replicating to itself: peerClusterId 67318852-e2b7-47a7-a303-f1722cb61a06
> which is not allowed by
> ReplicationEndpoint:org.apache.hadoop.hbase.replication.regionserver.HBaseInterClusterReplicationEndpoint{code}
> Here is the related code snippet which does this in the ReplicationSource
> class
> {code:java}
> // In rare case, zookeeper setting may be messed up. That leads to the
> incorrect
> // peerClusterId value, which is the same as the source clusterId
> if (clusterId.equals(peerClusterId) &&
> !replicationEndpoint.canReplicateToSameCluster()) {
> this.terminate("ClusterId " + clusterId + " is replicating to itself:
> peerClusterId "
> + peerClusterId + " which is not allowed by ReplicationEndpoint:"
> + replicationEndpoint.getClass().getName(), null, false);
> this.manager.removeSource(this);
> return;
> }{code}
> It would be good to have this logged at ERROR level instead of INFO for the
> following reasons
> 1. Under normal situation/case, the Peer Cluster ID would be different
> 2. It would help to easily troubleshoot issues that arises due to matching
> replication Peer cluster ID
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
