You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Varun Sharma (JIRA)" <ji...@apache.org> on 2013/04/06 22:37:15 UTC

[jira] [Created] (HBASE-8285) HBaseClient never recovers for single HTable.get() calls when regions move

Varun Sharma created HBASE-8285:
-----------------------------------

             Summary: HBaseClient never recovers for single HTable.get() calls when regions move
                 Key: HBASE-8285
                 URL: https://issues.apache.org/jira/browse/HBASE-8285
             Project: HBase
          Issue Type: Bug
          Components: Client
    Affects Versions: 0.94.6.1
            Reporter: Varun Sharma
            Assignee: Varun Sharma
            Priority: Critical
             Fix For: 0.94.7


Steps to reproduce this bug:
1) Gracefull restart a region server causing regions to get redistributed.
2) Client call to this region keeps failing since Meta Cache is never purged on the client for the region that moved.

Reason behind the bug:
1) Client continues to hit the old region server.
2) The old region server throws NotServingRegionException which is not handled correctly and the META cache entries are never purged for that server causing the client to keep hitting the old server.

The reason lies in ServerCallable code since we only purge META cache entries when there is a RetriesExhaustedException, SocketTimeoutException or ConnectException. However, there is no case check for NotServingRegionException(s).

Why is this not a problem for Scan(s) and Put(s) ?

a) If a region server is not hosting a region/scanner, then an UnknownScannerException is thrown which causes a relocateRegion() call causing a refresh of the META cache for that particular region.
b) For put(s), the processBatchCallback() interface in HConnectionManager is used which clears out META cache entries for all kinds of exceptions except DoNotRetryException.


--
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