[
https://issues.apache.org/jira/browse/HBASE-27691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18097634#comment-18097634
]
Andrew Olson edited comment on HBASE-27691 at 7/20/26 6:34 PM:
---------------------------------------------------------------
It appears this same bug was previously reported as HBASE-6562 but later
reverted (HBASE-6912). A proposed patch [^6562-0.96-v1.txt] that was never
committed appears appropriate for resolving this.
was (Author: noslowerdna):
It appears this same bug was previously fixed in HBASE-6562 but lost in later
refactoring.
> Fake Cell is being passed to Filters and comparators during StoreFileScans
> --------------------------------------------------------------------------
>
> Key: HBASE-27691
> URL: https://issues.apache.org/jira/browse/HBASE-27691
> Project: HBase
> Issue Type: Bug
> Components: scan, Scanners
> Affects Versions: 2.2.7
> Reporter: Tej Meka
> Priority: Major
> Attachments: image-2023-03-07-15-46-01-182.png,
> image-2023-03-07-15-50-59-696.png
>
>
> I am trying to upgrade HBase version (client and server) from 1.2.0 to 2.2.6
> and started seeing some unexpected behavior around discovery of ambiguous row
> in filter during StoreFileScans.
> *Is it a valid case that filters and Comparators might see a fake cell passed
> to them if that row is set as an inclusive(by default) start row to skip
> preceding row during Store file scans during client side execution?*
> When rows were persisted or updated on a table through bulkload, looks like a
> scan with specific column triggers a different behavior compared to a scan
> without columns which doesn't trigger this behavior.
> From what I have troubleshooted so far, it looks like this is triggered
> during [lazy
> scan|https://github.com/apache/hbase/blob/rel/2.2.6/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java#L251-L256]
> inside
> [StoreScanner|https://github.com/apache/hbase/blob/rel/2.2.6/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java#L406-L410]
> with
> [StoreFileScanner|https://github.com/apache/hbase/blob/rel/2.2.6/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileScanner.java#L388-L448]
> implementation where it eventually returns fake cell as current row on store
> heap
> [StoreFileScanner|https://github.com/apache/hbase/blob/rel/2.2.6/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileScanner.java#L437-L444]
> thus passed to filter but it's actually filtered later and not returned to
> client.
> This was not the case with hbase 1.7.2. I have created couple of simple Tests
> using hbase 1.7.2 and hbase 2.2.6 that bulkloads some sample rows to table
> and creates a column specific Scan to reproduce behavior that I have been
> talking about.
> I have simply copied KeyOnlyFilter, added few loggers to catch rowkeys being
> passed to filter and added few loggers to catch row keys returned as a result
> on client side.
> Here is my working repo that demonstrate this diverged behavior
> [hbase-scans|https://github.com/tejkiran/hbase-scans]
> I have a mapper that creates PUT with row keys 0, 2, 3 and bulkload those
> rows to table. When a scan is issued with 2.2.6 hbase API, it parses that
> start row on Scan to filter during server side execution.
> Screenshot of discovered row keys in filter during server side .
> !image-2023-03-07-15-46-01-182.png!
> Screenshoot of discovered row keys in filter with hbase 1.7.2
> !image-2023-03-07-15-50-59-696.png!
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
