[
https://issues.apache.org/jira/browse/HBASE-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-1219.
--------------------------
Resolution: Fixed
Fix Version/s: (was: 0.20.0)
Applied to branch (Doesn't make sense on trunk). Applied fix for 1219 and 1220
at same time.
> Scanners can miss values riding the flush transition
> ----------------------------------------------------
>
> Key: HBASE-1219
> URL: https://issues.apache.org/jira/browse/HBASE-1219
> Project: Hadoop HBase
> Issue Type: Bug
> Reporter: stack
> Priority: Blocker
> Fix For: 0.19.1
>
> Attachments: 1219.patch
>
>
> A scanner is made of a memcache scanner and a store files scanner. When a
> flush happens, the memcache content gets turned into a store file and is
> added to the list of already existing scanners. Currently the two scanners
> run autonomously. Ben Maurer points out that if we were returning values out
> of the memcache because they were of lower value than store file content, the
> lower pegging that was going on in memcache doesn't make it across when we
> pick up the memcache values in the flushed store file; we just keep on with
> whatever the lowest among the store files that were in place before the flush.
> Its a hard one to spot but should be easy to make a test for it.
> Ben Maurer also points out that in StoreFileScanner, we should not register
> the observer until after the scanners have been setup:
> {code}
> public StoreFileScanner(final Store store, final long timestamp,
> final byte [][] targetCols, final byte [] firstRow)
> throws IOException {
> super(timestamp, targetCols);
> this.store = store;
> this.store.addChangedReaderObserver(this);
> try {
> openScanner(firstRow);
> ...
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
