[
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, 9949.addendum
>
> 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
(v6.1#6144)
