[
https://issues.apache.org/jira/browse/HBASE-12971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14313782#comment-14313782
]
zhangduo commented on HBASE-12971:
----------------------------------
Just explain my thought here.
I think maxRetriesMultiplier carries two things here, one is max retry count,
and the other is max sleep time. I want to retry 300 times does not mean I want
to sleep 300s when last retry.
So I suggest to have two config here, maxRetryCount and maxRetrySleepTime. If
socketTimeout then just use maxRetrySleepTime.
Of course your solution can work for this issue [~lhofhansl], but I really
think we should use another model to calculate sleep time(base * retry is too
simple :) )
> Replication stuck due to large default value for
> replication.source.maxretriesmultiplier
> ----------------------------------------------------------------------------------------
>
> Key: HBASE-12971
> URL: https://issues.apache.org/jira/browse/HBASE-12971
> Project: HBase
> Issue Type: Bug
> Components: hbase
> Affects Versions: 1.0.0, 0.98.10
> Reporter: Adrian Muraru
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.94.27, 0.98.11
>
>
> We are setting in hbase-site the default value of 300 for
> {{replication.source.maxretriesmultiplier}} introduced in HBASE-11964.
> While this value works fine to recover for transient errors with remote ZK
> quorum from the peer Hbase cluster - it proved to have side effects in the
> code introduced in HBASE-11367 Pluggable replication endpoint, where the
> default is much lower (10).
> See:
> 1.
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSource.java#L169
> 2.
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/HBaseInterClusterReplicationEndpoint.java#L79
> The the two default values are definitely conflicting - when
> {{replication.source.maxretriesmultiplier}} is set in the hbase-site to 300
> this will lead to a sleep time of 300*300 (25h!) when a sockettimeout
> exception is thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
