[
https://issues.apache.org/jira/browse/HBASE-11667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14085660#comment-14085660
]
chunhui shen commented on HBASE-11667:
--------------------------------------
The logic of skipFirst is used to handle the case that client call 'next'
request and server returns the NSRE in the process of scanning.
I think it shouln't be removed directly.
For example, for a region contains rows: 'aaa','bbb','ccc','ddd'.
Do the following things:
1.Client open the scanner(empty start row) of this region.
2.Client call next, and get row 'aaa'
3.Move the region to another server
4.Client call next request to the old server, it will get NSRE, thus client
will open the scanner again with 'aaa'(the last result) as the start row.
5.Client should skip the first row 'aaa'
So, for the test case testScansWithSplits(), we should do
"TEST_UTIL.getHBaseAdmin().split(TABLE)" in the process of scanning rather than
after completing scanning.
Pardon me if something wrong.
> 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, 0.98.5, 2.0.0, 0.94.23
>
> Attachments: 11667-0.94.txt, 11667-trunk.txt, HBASE-11667-0.98.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)
