[ 
https://issues.apache.org/jira/browse/HBASE-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118918#comment-13118918
 ] 

Lars Hofhansl commented on HBASE-4334:
--------------------------------------

In turns out that coprocessor can - legitimately - call 
HRegion.getScanner(Scan) without specifying a startkey. That works because 
coprocessors are already region scoped. AggregateImplementation does that for 
example.

There are various alternatives:
1. add getScanner(..., boolean check) that avoid that check. Coprocessors can 
then call that method.
2. Force coprocessor to set the start key. (i.e. just fail here too)
3. Handle gets and scans separately. Intercept scanners in 
HRegionServer.openScanner and do the check there.
4. Have RegionCoprocessorInterface return a wrapper of HRegion, where 
getScanner(...) would call would call an internal method avoiding the check. 
This would require extracting an interface for HRegion. Or maybe a 
RegionServices interface.
5. Just check whether the scanner intersects (includes containing) the region. 
Works fine for gets. Won't catch all cases for scans.

#1 and #2 are not obvious to the implementer of a coprocessor.

Leaning towards #3.
                
> HRegion.get never validates row
> -------------------------------
>
>                 Key: HBASE-4334
>                 URL: https://issues.apache.org/jira/browse/HBASE-4334
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>    Affects Versions: 0.90.4
>            Reporter: Joe Pallas
>            Assignee: Lars Hofhansl
>             Fix For: 0.92.0
>
>         Attachments: 4334-v2.txt, 4334.txt
>
>
> If a client gets confused (possibly by a hole in .META., see HBASE-4333), it 
> may send a request to the wrong region.  Paths through put, delete, 
> incrementColumnValue, and checkAndMutate all call checkRow either directly or 
> indirectly (through getLock).  But get apparently does not.  This can result 
> in returning an incorrect empty result instead of a WrongRegionException.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to