[
https://issues.apache.org/jira/browse/CASSANDRA-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14312508#comment-14312508
]
Alan Boudreault commented on CASSANDRA-8683:
--------------------------------------------
The test I am running is testv2.sh from CASSANDRA-8366. Currently running it
with DEBUG log enabled. I will attach when finish.
> Ensure early reopening has no overlap with replaced files
> ---------------------------------------------------------
>
> Key: CASSANDRA-8683
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8683
> Project: Cassandra
> Issue Type: Bug
> Reporter: Marcus Eriksson
> Assignee: Benedict
> Priority: Critical
> Fix For: 2.1.3
>
> Attachments: 0001-avoid-NPE-in-getPositionsForRanges.patch
>
>
> When introducing CASSANDRA-6916 we permitted the early opened files to
> overlap with the files they were replacing by one DecoratedKey, as this
> permitted a few minor simplifications. Unfortunately this breaks assumptions
> in LeveledCompactionScanner, that are causing the intermittent unit test
> failures:
> http://cassci.datastax.com/job/trunk_utest/1330/testReport/junit/org.apache.cassandra.db.compaction/LeveledCompactionStrategyTest/testValidationMultipleSSTablePerLevel/
> This patch by itself does not fix the bug, but fixes the described aspect of
> it, by ensuring the replaced and replacing files never overlap. This is
> achieved first by always selecting the replaced file start as the next key
> present in the file greater than the last key in the new file(s). If there
> is no such key, however, there is no data to return for the reader, but to
> permit abort and atomic replacement at the end of a macro compaction action,
> we must keep the file in the DataTracker for replacement purposes, but not
> return it to consumers (esp. as many assume a non-empty range). For this I
> have introduced a new OpenReason called SHADOWED, and a
> DataTracker.View.shadowed collection of sstables, that tracks those we still
> consider to be in the live set, but from which we no longer answer any
> queries.
> CASSANDRA-8744 (and then CASSANDRA-8750) then ensures that these bounds are
> honoured, so that we never break the assumption that files in LCS never
> overlap.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
