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

Andrew Kyle Purtell commented on HBASE-24069:
---------------------------------------------

bq. Is this primarily meant to deal with the case where the RS might be busy in 
responding to the close request temporarily because of incoming load but might 
get free in some time where the retry without exponentialBackOff would quickly 
fail it to FAILED_CLOSE state ? 

Yes, this is what we have seen in production. 

bq. Can you please help me understand the case where the SPLIT request would 
ultimately end up in FAILED_CLOSE state ? 

The objective here is AM actions with respect to splits should also use 
exponential backoff, to be consistent with the strategy of other requests, and 
to lower the probability of split failure due to rapid exhaustion of retries. 

> Extend HBASE-16209 strategy (Provide an ExponentialBackOffPolicy sleep 
> between failed region open requests) to region close and split requests
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-24069
>                 URL: https://issues.apache.org/jira/browse/HBASE-24069
>             Project: HBase
>          Issue Type: Improvement
>          Components: Region Assignment
>    Affects Versions: 1.6.0
>            Reporter: Andrew Kyle Purtell
>            Assignee: Sandeep Guggilam
>            Priority: Major
>             Fix For: 3.0.0-alpha-1, 1.7.0, 2.4.0
>
>
> In HBASE-16209 we provide an ExponentialBackOffPolicy sleep between failed 
> region open requests. This should be extended to also apply to region close 
> and split requests. Will reduce the likelihood of FAILED_CLOSE transitions in 
> production by being more tolerant of temporary regionserver loading issues, 
> e.g. CallQueueTooBigException.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to