hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-1831) Scanning API must be reworked to allow for fully functional Filters client-side
Date Wed, 23 Sep 2009 05:05:15 GMT

    [ 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.

View raw message