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