hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-9949) Fix the race condition between Compaction and StoreScanner.init
Date Sun, 01 Dec 2013 00:44:36 GMT

     [ https://issues.apache.org/jira/browse/HBASE-9949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Lars Hofhansl updated HBASE-9949:

    Fix Version/s: 0.96.2

Adding 0.96 bit, as this as also committed to 0.96. (not sure whether this is in 0.96.1 or
0.96.2, though).
Now, this seems important to fix in 0.94 as well - if I read this right we can lose data...?

The updateReaders bit is a bit scary. I am in this code a bit these days. Another option would
be to block reader updates until after he compaction/flush is finished, that would be relatively
easy to do by just locking the StoreScanner in question for the entire duration of the compaction
(updateReaders would then block until the StoreScanner is released).

> Fix the race condition between Compaction and StoreScanner.init
> ---------------------------------------------------------------
>                 Key: HBASE-9949
>                 URL: https://issues.apache.org/jira/browse/HBASE-9949
>             Project: HBase
>          Issue Type: Bug
>          Components: Scanners
>    Affects Versions: 0.89-fb
>            Reporter: Manukranth Kolloju
>            Assignee: Manukranth Kolloju
>            Priority: Minor
>             Fix For: 0.89-fb, 0.98.0, 0.96.2
>         Attachments: 9949-0.96.addendum, 9949-trunk-v1.txt, 9949-trunk-v2.txt, 9949-trunk-v3.txt,
>   Original Estimate: 48h
>  Remaining Estimate: 48h
> The StoreScanner constructor has multiple stages and there can be a race betwwen an ongoing
compaction and the StoreScanner constructor where we might get the list of scanners before
a compaction and seek on those scanners after the compaction.

This message was sent by Atlassian JIRA

View raw message