[ https://issues.apache.org/jira/browse/HBASE-11667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14088331#comment-14088331 ]
Hudson commented on HBASE-11667: -------------------------------- SUCCESS: Integrated in HBase-0.94-security #509 (See [https://builds.apache.org/job/HBase-0.94-security/509/]) HBASE-11667 Comment ClientScanner logic for NSREs. (larsh: rev c51e19afec1925de7769c24e0dbd2bfcf90a184e) * src/main/java/org/apache/hadoop/hbase/client/ClientScanner.java > 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)