[
https://issues.apache.org/jira/browse/HBASE-11667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14085913#comment-14085913
]
Lars Hofhansl commented on HBASE-11667:
---------------------------------------
bq. We should come up with a test that finds out. Might be a bug issue there.
Not a bug, I think, just unnecessary work. I also do not see any other way of
doing this. When a region moves even from a logical viewpoint you *need* to
know where to start off again or you have to start from last known position
(which is the start key of the last region).
I suppose every scan could always send the last row seen as extra metadata at
the end of the RPC. The ClientScanner would record that, but not pass it on to
the caller. That would still break the Phoenix scenario that started this
discussion though, as the region observer does not send a useful row key back
at all.
> 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)
