Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 5 Aug 2014 07:20:12 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12731897.1407196131470.14967.1407223212455@arcas>
In-Reply-To: <JIRA.12731897.1407196131470@arcas>
References: <JIRA.12731897.1407196131470@arcas>
Subject: [jira] [Commented] (HBASE-11667) Comment ClientScanner logic for
 NSREs.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Andrew Purtell commented on HBASE-11667:
----------------------------------------

bq. I suppose every scan could always send the last row seen as extra metadata at the end of the RPC. 

That wouldn't help. It's suspicious that the client relies on the server telling it state it could track locally (or am I missing something?). In the Phoenix case the server lies because a coprocessor changes something, and the client cannot recover, but could/should?

> Comment ClientScanner logic for NSREs.
> --------------------------------------
>
>                 Key: HBASE-11667
>                 URL: https://issues.apache.org/jira/browse/HBASE-11667
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>            Priority: Minor
>             Fix For: 0.99.0, 2.0.0, 0.94.23, 0.98.6
>
>         Attachments: 11667-0.94.txt, 11667-doc-0.94.txt, 11667-trunk.txt, HBASE-11667-0.98.patch, IntegrationTestBigLinkedListWithRegionMovement.patch
>
>
> We ran into an issue with Phoenix where a RegionObserver coprocessor intercepts a scan and returns an aggregate (in this case a count) with a fake row key. It turns out this does not work when the {{ClientScanner}} encounters NSREs, as it uses the last key it saw to reset the scanner to try again (which in this case would be the fake key).
> While this is arguably a rare case and one could also argue that a region observer just shouldn't do this... While looking at {{ClientScanner}}'s code I found this logic not necessary.
> A NSRE occurred because we contacted a region server with a key that it no longer hosts. This is the start key, so it is always correct to retry with this same key. That simplifies the ClientScanner logic and also make this sort of coprocessors possible,


--
This message was sent by Atlassian JIRA
(v6.2#6252)