[
https://issues.apache.org/jira/browse/HBASE-19359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16305907#comment-16305907
]
Guanghao Zhang commented on HBASE-19359:
----------------------------------------
{code}
public static final int [] RETRY_BACKOFF = {1, 2, 3, 5, 10, 20, 40, 100, 100,
100, 100, 200, 200};
public static final long DEFAULT_HBASE_CLIENT_PAUSE = 100;
{code}
So the default sleep time for each retry is: 100ms, 200ms, 300ms, 500ms, 1s,
2s, 4s, 10s, 10s, 10s, 10s, 20s... So if MTTR is 120s, 10 times retry is not
enough. I thought the problem is we only have one backoff calculation method
and it is not a real exponential backoff. A real exponential backoff should {1,
2, 3, 5, 10, 20, 40, 100, 200, 400, 1000} ? And for "hit the blocking store
file limit" problem, we already now it will stop write 90s, can be break this
information to client? Then client can use this information to calculate
backoff. Same problem for ThrottlingException and CallQueueTooBigException.
> Revisit the default config of hbase client retries number
> ---------------------------------------------------------
>
> Key: HBASE-19359
> URL: https://issues.apache.org/jira/browse/HBASE-19359
> Project: HBase
> Issue Type: Sub-task
> Reporter: Guanghao Zhang
> Assignee: Guanghao Zhang
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19359.master.001.patch,
> HBASE-19359.master.001.patch, HBASE-19359.master.001.patch
>
>
> This should be sub-task of HBASE-19148. As the retries number effect too many
> unit tests. So I open this issue to see the Hadoop QA result.
> The default value of hbase.client.retries.number is 35. Plan to reduce this
> to 10.
> And for server side, the default hbase.client.serverside.retries.multiplier
> is 10. So the server side retries number is 35 * 10 = 350. It is too big!
> Plan to reduce hbase.client.serverside.retries.multiplier to 3.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
