You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Ashu Pachauri (JIRA)" <ji...@apache.org> on 2015/12/10 03:31:10 UTC

[jira] [Commented] (HBASE-14953) HBaseInterClusterReplicationEndpoint: Do not retry the whole batch of edits in case of RejectedExecutionException

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

Ashu Pachauri commented on HBASE-14953:
---------------------------------------

To give more context on why we really need to do this:
1. This impacts replication performance, because we are retrying unnecessarily.
2. The more pressing concern is that this creates significant extra traffic to peer clusters, because a good chunk of edits already sent across the wire (which would potentially succeed) are resent. This translates into more load on both the clusters.
3. Clutters the logs with too many warning. The major portion of logs is filled with these exceptions.
These factors become more significant in a high traffic environment. 

> HBaseInterClusterReplicationEndpoint: Do not retry the whole batch of edits in case of RejectedExecutionException
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-14953
>                 URL: https://issues.apache.org/jira/browse/HBASE-14953
>             Project: HBase
>          Issue Type: Bug
>          Components: Replication
>    Affects Versions: 2.0.0, 1.2.0, 1.3.0
>            Reporter: Ashu Pachauri
>            Assignee: Ashu Pachauri
>         Attachments: HBASE-14953-V1.patch
>
>
> When we have wal provider set to multiwal, the ReplicationSource has multiple worker threads submitting batches to HBaseInterClusterReplicationEndpoint. In such a scenario, it is quite common to encounter RejectedExecutionException because it takes quite long for shipping edits to peer cluster compared to reading edits from source and submitting more batches to the endpoint. 
> The logs are just filled with warnings due to this very exception.
> Since we subdivide batches before actually shipping them, we don't need to fail and resend the whole batch if one of the sub-batches fails with RejectedExecutionException. Rather, we should just retry the failed sub-batches. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)