[
https://issues.apache.org/jira/browse/HBASE-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-17328:
-----------------------------------
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
I committed this to all active branches, picking and fixing up as necessary.
Thanks for the contribution [~vincentpoon] !
Confirmed the new unit in TestMasterReplication passed everywhere.
> Properly dispose of looped replication peers
> --------------------------------------------
>
> Key: HBASE-17328
> URL: https://issues.apache.org/jira/browse/HBASE-17328
> Project: HBase
> Issue Type: Bug
> Components: Replication
> Affects Versions: 2.0.0, 1.4.0, 0.98.23
> Reporter: Vincent Poon
> Assignee: Vincent Poon
> Priority: Critical
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.5, 1.1.9, 0.98.24
>
> Attachments: HBASE-17328-1.1.v1.patch, HBASE-17328-master.v1.patch,
> HBASE-17328-master.v2.patch, HBASE-17328.0.98.v4.patch,
> HBASE-17328.branch-1.1.v2.patch, HBASE-17328.branch-1.1.v3.patch,
> HBASE-17328.branch-1.1.v4.patch, HBASE-17328.master.v4.patch
>
>
> When adding a looped replication peer (clusterId == peerClusterId), the
> following code terminates the replication source thread, but since the source
> manager still holds a reference, WALs continue to get enqueued, and never get
> cleaned because they're stuck in the queue, leading to an unsustainable
> buildup. Furthermore, the replication statistics thread will continue to
> print statistics for the terminated source.
> {code}
> 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);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
