[ https://issues.apache.org/jira/browse/HBASE-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15762308#comment-15762308 ]
Vincent Poon commented on HBASE-17328: -------------------------------------- Ah yes, in that case my v2 patch for master was correct after all. uninitialize() isn't needed because terminate() closes the endpoint, and manager.closeQueue() clears the metrics. Uploaded a new v3 for branch-1.1 > 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, > HBASE-17328-master.v2.patch, HBASE-17328.branch-1.1.v2.patch, > HBASE-17328.branch-1.1.v3.patch, HBASE-17328.branch-1.1.v3.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)