hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Shelukhin (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HBASE-8777) HBase client should determine the destination server after retry time
Date Wed, 04 Dec 2013 19:00:36 GMT

     [ https://issues.apache.org/jira/browse/HBASE-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Sergey Shelukhin resolved HBASE-8777.

    Resolution: Won't Fix

probably too late for 94

> HBase client should determine the destination server after retry time
> ---------------------------------------------------------------------
>                 Key: HBASE-8777
>                 URL: https://issues.apache.org/jira/browse/HBASE-8777
>             Project: HBase
>          Issue Type: Improvement
>          Components: Client
>    Affects Versions: 0.94.9
>            Reporter: Sergey Shelukhin
> HBase currently determines which server to go to, then creates delayed callable with
pre-determined server and goes there. For later 16-32-... second retries this approach is
suboptimal, the cluster could have seen massive changes in the meantime, so retry might be
completely useless.
> We should re-locate regions after the delay, at least for longer retries. Given how grouping
is currently done it would be a bit of a refactoring.
> The effect of this is alleviated (to a degree) on trunk by server-based retries (if we
fail going to the pre-delay server after delay and then determine the server has changed,
we will go to the new server immediately, so we only lose the failed round-trip time); on
94, if the region is opened on some other server during the delay, we'd go to the old one,
fail, then find out it's on different server, wait a bunch more time because it's a late-stage
retry and THEN go to the new one, as far as I see. 

This message was sent by Atlassian JIRA

View raw message