[
https://issues.apache.org/jira/browse/HBASE-11667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14085803#comment-14085803
]
Lars Hofhansl commented on HBASE-11667:
---------------------------------------
I think I see what the issue is now. Each RPC needs to set the correct startRow
as it might just hit the next region. My patch removes exactly that part. Hence
an NSRE in any but the first round would redo scanning from the previous
startKey, which then might rescan the last batch (and hence the number of extra
rows scanned is always the caching setting).
Will close as "Invalid" unless somebody has more ideas.
> Simplify 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
> Fix For: 0.99.0, 2.0.0, 0.94.23, 0.98.6
>
> Attachments: 11667-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)
