[
https://issues.apache.org/jira/browse/HBASE-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-17328:
-----------------------------------
Fix Version/s: 1.1.9
0.98.24
1.2.5
1.4.0
1.3.0
2.0.0
> 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, 0.98.24, 1.1.9
>
> Attachments: HBASE-17328-1.1.v1.patch, HBASE-17328-master.v1.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)
