Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 22 Sep 2017 11:38:00 +0000 (UTC)
From: "Abhishek Singh Chouhan (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13101624.1505219437000.175389.1506080280208@Atlassian.JIRA>
In-Reply-To: <JIRA.13101624.1505219437000@Atlassian.JIRA>
References: <JIRA.13101624.1505219437000@Atlassian.JIRA> <JIRA.13101624.1505219437837@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HBASE-18796) Admin#isTableAvailable returns
 incorrect result before daughter regions are opened
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 22 Sep 2017 11:38:06 -0000


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