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

nkeywal commented on HBASE-7649:
--------------------------------

bq. Well, the region can often be opened very quickly, so I think it might make 
sense to try to go to destination immediately. I am aware of some schemes in 
certain products where the server tries to calculate backoff time based on 
request queue under heavy load, and tells the client to back off for that time, 
but that seems like it's too much of a high hanging fruit right now

The bad scenario would be:
dead rs -> new rs to early -> meta -> new rs (on time)

This makes us as slow as today and adds a call to meta. Even if the open/close 
is very fast, the common use case is likely to be a continuous flow of writes 
by the client interrupted by a balance, so the client will get the info at the 
very beginning of the move. As a consequence, the bad scenario above may be 
more common that we would like. But I don't have a definitive opinion on the 
best choice between always waiting and never waiting, so I will follow the 
general opinion here.





                
> client retry timeout doesn't need to do x2 fallback when going to different 
> server
> ----------------------------------------------------------------------------------
>
>                 Key: HBASE-7649
>                 URL: https://issues.apache.org/jira/browse/HBASE-7649
>             Project: HBase
>          Issue Type: Improvement
>          Components: Client
>            Reporter: Sergey Shelukhin
>            Assignee: Sergey Shelukhin
>         Attachments: HBASE-7649-v0.patch, HBASE-7649-v1.patch, 
> HBASE-7649-v2.patch, HBASE-7649-v2.patch, HBASE-7649-v2.patch, 
> HBASE-7649-v3.patch
>
>
> See HBASE-7520. When we go to server A, get a bunch of failures, then finally 
> learn the region is on B it doesn't make sense to wait for 30 seconds before 
> going to B.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to