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

Guanghao Zhang commented on HBASE-17958:
----------------------------------------

When optimize seek to skip, it will call next to next column/row. But the 
heap's current scanner maybe changed when call next. The new scanner maybe not 
seeked because the laze seek feature. So TestBlocksRead failed. One solution is 
decide whether to optimize before every next call. Attach a v6 patch which 
showed the solution.

> Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP
> ----------------------------------------------------------------------------
>
>                 Key: HBASE-17958
>                 URL: https://issues.apache.org/jira/browse/HBASE-17958
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Guanghao Zhang
>            Assignee: Guanghao Zhang
>         Attachments: 0001-add-one-ut-testWithColumnCountGetFilter.patch, 
> HBASE-17958-v1.patch, HBASE-17958-v2.patch, HBASE-17958-v3.patch, 
> HBASE-17958-v4.patch, HBASE-17958-v5.patch, HBASE-17958-v6.patch
>
>
> {code}
> ScanQueryMatcher.MatchCode qcode = matcher.match(cell);
> qcode = optimize(qcode, cell);
> {code}
> The optimize method may change the MatchCode from SEEK_NEXT_COL/SEEK_NEXT_ROW 
> to SKIP. But it still pass the next cell to ScanQueryMatcher. It will get 
> wrong result when use some filter, etc. ColumnCountGetFilter. It just count 
> the  columns's number. If pass a same column to this filter, the count result 
> will be wrong. So we should avoid passing cell to ScanQueryMatcher when 
> optimize SEEK to SKIP.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to