[
https://issues.apache.org/jira/browse/HBASE-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758584#action_12758584
]
stack commented on HBASE-1831:
------------------------------
Chatted with Jon.
1. Need to flag client to STOP. HTable#next internally uses the batch version
of next (so can do prefetching of rows). An empty list of Results is always
sent -- never null. We'll add passing null as the flag that filter is done;
do not move to next region (Client has code to handle null list so if an old
hbase version connects, it won't break; it'll just not do the STOP properly).
2. There is a non-batch next in the ipc interface. I was thinking of
deprecating it and moving internals to use the batch interface only, but these
internal uses of scanners do not carry filters so will just leave them for
0.20.1.
3. Filters carry state. How do we get the state across region transitions?
Again chatting with Jon, will do the following. If a Scanner has a filter, and
we got back a non-empty list, its time to move to the next region. Just before
we move to the next region, we'll make another call to the old server --
Scanner.getFilter -- whose result is the deserialized filter. The deserialized
filter will be passed then to the next region. In this manner filters will be
able to carry their state forward. Downside is extra RPC call IF scanning with
a filter.
> Scanning API must be reworked to allow for fully functional Filters
> client-side
> -------------------------------------------------------------------------------
>
> Key: HBASE-1831
> URL: https://issues.apache.org/jira/browse/HBASE-1831
> Project: Hadoop HBase
> Issue Type: Bug
> Affects Versions: 0.20.0
> Reporter: Jonathan Gray
> Priority: Critical
> Fix For: 0.20.1, 0.21.0
>
>
> Right now, a client replays part of the Filter locally by calling
> filterRowKey() and filterAllRemaining() to determine whether it should
> continue to the next region.
> A number of new filters rely on filterKeyValue() and other calls to alter
> state. It's also a false assumption that all rows/keys affecting a filter
> returning true for FAR will be seen client-side (what about those that failed
> the filter).
> This issue is about dealing with Filters properly from the client-side.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
