[
https://issues.apache.org/jira/browse/HBASE-11667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-11667:
----------------------------------
Attachment: 11667-0.94.txt
Here's a *proposal* against 0.94.
Please have a very careful look, as there might be corner conditions lurking
that I have not seen.
I ran TestFromClientSide (including the new test I added) and it worked fine.
Since we retry with the previous key that caused the failure, all the skipFirst
huh-hah just goes away, which is nice.
> 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
>
>
> 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)
