[
https://issues.apache.org/jira/browse/HBASE-11667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14087161#comment-14087161
]
Lars Hofhansl commented on HBASE-11667:
---------------------------------------
bq. Keeping last thing we delivered – state – would purge all that is grey in
this area.
In a sense we do, and then use only when encountering a NRSE exception. If we
just remember what we delivered (and don't require a real key) we'd always have
to rescan the entire region upon a NSRE (not just the last rows worth of
scanner caching) and then ignore everything we delivered so far. So definitely
less efficient, and might lead to other weird issues if scans do not return the
exact same row keys upon repeated execution (for example when a filter or
region observer messes with things).
I'll commit the comment update to all branches for now; but I'll keep thinking
about this. This is ugly right now, especially in trunk with the region
replicas.
> 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)
