[jira] [Updated] (HBASE-11667) Comment ClientScanner logic for NSREs.
[
https://issues.apache.org/jira/browse/HBASE-11667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-11667:
--
Attachment: (was: 11667-doc-0.94.txt)
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-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)
[jira] [Updated] (HBASE-11667) Comment ClientScanner logic for NSREs.
[
https://issues.apache.org/jira/browse/HBASE-11667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-11667:
--
Summary: Comment ClientScanner logic for NSREs. (was: Simplify
ClientScanner logic for NSREs.)
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-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)
[jira] [Updated] (HBASE-11667) Comment ClientScanner logic for NSREs.
[
https://issues.apache.org/jira/browse/HBASE-11667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-11667:
--
Attachment: 11667-doc-0.94.txt
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)
