hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Abhishek Singh Chouhan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-18796) Admin#isTableAvailable returns incorrect result before daughter regions are opened
Date Fri, 22 Sep 2017 11:38:00 GMT

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

Abhishek Singh Chouhan commented on HBASE-18796:
------------------------------------------------

[~apurtell] The addendum might not be correct solution to this problem and might cause a problem
elsewhere. I think we should hold on to committing that.
I had a bit more look into the behavior. Scan.next says that we should either get values or
we get null if the scanner is exhausted. This doesn't seem to be the case hence we're getting
the issue here.
In the client scanner 
values = call(callable, caller, scannerTimeout, true);
we get a single element in the Result[] values array. Now we proceed to
Result[] resultsToAddToCache =
          scanResultCache.addAndGet(values, callable.isHeartbeatMessage());
int numberOfCompleteRows =
          scanResultCache.numberOfCompleteRows() - numberOfCompleteRowsBefore;

In CompleteScanResultCache#addAndGet we have the code:
{code}
Result last = results[results.length - 1];
    if (last.mayHaveMoreCellsInRow()) {
      if (partialResults.isEmpty()) {
        partialResults.add(last);
        return updateNumberOfCompleteResultsAndReturn(Arrays.copyOf(results, results.length
- 1));
      }
{code}
here since results.length = 1 and last.mayHaveMoreCellsInRow() is true we add the result we
got into partialResults however the completed results is 0.  
We end up in  (have to look more into this part)
if (scan.getLimit() == 0 || scanExhausted(values)) {
        closeScanner();
        closed = true;
        break;
      }
and end up returning null to the client which should not be the case. We should open another
jira for this. Setting allowpartial in ConnectionImplementation might be the wrong thing to
do that has other side effects and might hide the actual problem.
Someone with more familiarity on the partial scanning side should have more insights. I'll
dig into this more tomorrow. In the meantime if we want to just fix the test we can add isTableEnabled()
in the wait for split which would make it more robust since checking just number of regions
might be a false indicator of successful split.

[~tedyu] [~apurtell] [~lhofhansl]

> Admin#isTableAvailable returns incorrect result before daughter regions are opened
> ----------------------------------------------------------------------------------
>
>                 Key: HBASE-18796
>                 URL: https://issues.apache.org/jira/browse/HBASE-18796
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 1.3.1
>            Reporter: Abhishek Singh Chouhan
>            Assignee: Abhishek Singh Chouhan
>             Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.5.0
>
>         Attachments: HBASE-18796-addendum.branch-1.patch, HBASE-18796-addendum.master.patch,
HBASE-18796.branch-1.001.patch, HBASE-18796.branch-1.001.patch, HBASE-18796.branch-1.002.patch,
HBASE-18796.branch-1.003.patch, HBASE-18796.master.001.patch
>
>
> Admin#isTableAvailable checks if it can getServerName for the meta entries it reads.
During the time of split server location are added to the meta entries in MetaTableAccessor#splitRegion
although the description of the method says "Does not add the location information to the
daughter regions since they are not open yet.". At this point during the split daughter regions
are not actually open, so we can get to a state where parent is offline, daughters are not
yet open but isTableAvailable returns true.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message