[jira] [Commented] (HBASE-20855) PeerConfigTracker only supporting one listener will cause problem when there is a recovered replication queue
[ https://issues.apache.org/jira/browse/HBASE-20855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550658#comment-16550658 ] Hudson commented on HBASE-20855: Results for branch branch-1 [build #386 on builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/386/]: (x) *{color:red}-1 overall{color}* details (if available): (x) {color:red}-1 general checks{color} -- For more information [see general report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/386//General_Nightly_Build_Report/] (x) {color:red}-1 jdk7 checks{color} -- For more information [see jdk7 report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/386//JDK7_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-1/386//JDK8_Nightly_Build_Report_(Hadoop2)/] (x) {color:red}-1 source release artifact{color} -- See build output for details. > PeerConfigTracker only supporting one listener will cause problem when there > is a recovered replication queue > - > > Key: HBASE-20855 > URL: https://issues.apache.org/jira/browse/HBASE-20855 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0, 1.5.0 >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Fix For: 1.5.0, 1.4.6 > > Attachments: HBASE-20855.branch-1.001.patch, > HBASE-20855.branch-1.002.patch, HBASE-20855.branch-1.003.patch, > HBASE-20855.branch-1.004.patch, HBASE-20855.branch-1.005.patch, > HBASE-20855.branch-1.006.patch, HBASE-20855.branch-1.007.patch > > > {code} > public void init(Context context) throws IOException { > this.ctx = context; > if (this.ctx != null){ > ReplicationPeer peer = this.ctx.getReplicationPeer(); > if (peer != null){ > peer.trackPeerConfigChanges(this); > } else { > LOG.warn("Not tracking replication peer config changes for Peer Id " + > this.ctx.getPeerId() + > " because there's no such peer"); > } > } > } > {code} > As we know, replication source will set itself to the PeerConfigTracker in > ReplicationPeer. When there is one or more recovered queue, each queue will > generate a new replication source, But they share the same ReplicationPeer. > Then when it calls setListener, the new generated one will cover the older > one. Thus there will only has one ReplicationPeer that receive the peer > config change notify. > {code} > public synchronized void setListener(ReplicationPeerConfigListener listener){ > this.listener = listener; > } > {code} > > To solve this, PeerConfigTracker need to support multiple listener and > listener should be removed when the replication endpoint terminated. > I will upload a patch later with fix and UT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20855) PeerConfigTracker only supporting one listener will cause problem when there is a recovered replication queue
[ https://issues.apache.org/jira/browse/HBASE-20855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550115#comment-16550115 ] Jingyun Tian commented on HBASE-20855: -- [~yuzhih...@gmail.com] Sure. I'll update a patch asap. > PeerConfigTracker only supporting one listener will cause problem when there > is a recovered replication queue > - > > Key: HBASE-20855 > URL: https://issues.apache.org/jira/browse/HBASE-20855 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.0, 1.4.0, 1.5.0 >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Fix For: 1.5.0, 1.4.6 > > Attachments: HBASE-20855.branch-1.001.patch, > HBASE-20855.branch-1.002.patch, HBASE-20855.branch-1.003.patch, > HBASE-20855.branch-1.004.patch, HBASE-20855.branch-1.005.patch, > HBASE-20855.branch-1.006.patch, HBASE-20855.branch-1.007.patch > > > {code} > public void init(Context context) throws IOException { > this.ctx = context; > if (this.ctx != null){ > ReplicationPeer peer = this.ctx.getReplicationPeer(); > if (peer != null){ > peer.trackPeerConfigChanges(this); > } else { > LOG.warn("Not tracking replication peer config changes for Peer Id " + > this.ctx.getPeerId() + > " because there's no such peer"); > } > } > } > {code} > As we know, replication source will set itself to the PeerConfigTracker in > ReplicationPeer. When there is one or more recovered queue, each queue will > generate a new replication source, But they share the same ReplicationPeer. > Then when it calls setListener, the new generated one will cover the older > one. Thus there will only has one ReplicationPeer that receive the peer > config change notify. > {code} > public synchronized void setListener(ReplicationPeerConfigListener listener){ > this.listener = listener; > } > {code} > > To solve this, PeerConfigTracker need to support multiple listener and > listener should be removed when the replication endpoint terminated. > I will upload a patch later with fix and UT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20855) PeerConfigTracker only supporting one listener will cause problem when there is a recovered replication queue
[ https://issues.apache.org/jira/browse/HBASE-20855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549812#comment-16549812 ] Hudson commented on HBASE-20855: Results for branch branch-1.4 [build #390 on builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/390/]: (x) *{color:red}-1 overall{color}* details (if available): (x) {color:red}-1 general checks{color} -- For more information [see general report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/390//General_Nightly_Build_Report/] (x) {color:red}-1 jdk7 checks{color} -- For more information [see jdk7 report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/390//JDK7_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-1.4/390//JDK8_Nightly_Build_Report_(Hadoop2)/] (x) {color:red}-1 source release artifact{color} -- See build output for details. > PeerConfigTracker only supporting one listener will cause problem when there > is a recovered replication queue > - > > Key: HBASE-20855 > URL: https://issues.apache.org/jira/browse/HBASE-20855 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.0, 1.4.0, 1.5.0 >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Fix For: 1.5.0, 1.4.6 > > Attachments: HBASE-20855.branch-1.001.patch, > HBASE-20855.branch-1.002.patch, HBASE-20855.branch-1.003.patch, > HBASE-20855.branch-1.004.patch, HBASE-20855.branch-1.005.patch, > HBASE-20855.branch-1.006.patch, HBASE-20855.branch-1.007.patch > > > {code} > public void init(Context context) throws IOException { > this.ctx = context; > if (this.ctx != null){ > ReplicationPeer peer = this.ctx.getReplicationPeer(); > if (peer != null){ > peer.trackPeerConfigChanges(this); > } else { > LOG.warn("Not tracking replication peer config changes for Peer Id " + > this.ctx.getPeerId() + > " because there's no such peer"); > } > } > } > {code} > As we know, replication source will set itself to the PeerConfigTracker in > ReplicationPeer. When there is one or more recovered queue, each queue will > generate a new replication source, But they share the same ReplicationPeer. > Then when it calls setListener, the new generated one will cover the older > one. Thus there will only has one ReplicationPeer that receive the peer > config change notify. > {code} > public synchronized void setListener(ReplicationPeerConfigListener listener){ > this.listener = listener; > } > {code} > > To solve this, PeerConfigTracker need to support multiple listener and > listener should be removed when the replication endpoint terminated. > I will upload a patch later with fix and UT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)