[jira] [Updated] (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:all-tabpanel ] Andrew Purtell updated HBASE-20855: --- Fix Version/s: (was: 1.5.0) > 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.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] [Updated] (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:all-tabpanel ] Jingyun Tian updated HBASE-20855: - Affects Version/s: (was: 1.3.0) > 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] [Updated] (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:all-tabpanel ] Andrew Purtell updated HBASE-20855: --- Resolution: Fixed Status: Resolved (was: Patch Available) > 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] [Updated] (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:all-tabpanel ] Ted Yu updated HBASE-20855: --- Hadoop Flags: Reviewed Fix Version/s: 1.4.6 1.5.0 Integrated to branch-1.4 and branch-1 Doesn't apply to branch-1.3 Please attach patch for branch-1.3 > 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] [Updated] (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:all-tabpanel ] Ted Yu updated HBASE-20855: --- Summary: PeerConfigTracker only supporting one listener will cause problem when there is a recovered replication queue (was: PeerConfigTracker only support one listener will cause problem when there is a recovered replication queue) > 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 > 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)