[jira] [Commented] (HBASE-17328) Properly dispose of looped replication peers

["Ted Yu (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15755940#comment-15755940 ] 

Ted Yu commented on HBASE-17328:
--------------------------------

{code}
330	      this.manager.removeSource(this);
331	      this.replicationQueues.removeQueue(peerId);
332	      uninitialize();
333	      return;
{code}
The above should be placed ahead of the terminate() call, right ?

> 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
>         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)