[
https://issues.apache.org/jira/browse/CASSANDRA-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14312295#comment-14312295
]
Benedict commented on CASSANDRA-8683:
-------------------------------------
bq. Edit: or, it doesn't since we don't notify compaction strategies about
early opened files, but that only makes everything more confusing
Agreed this is confusing. As part of cleaning up the whole pig we've been
trying to put lipstick on for a while, we should consider if there's a better
approach in general to keeping compaction strategies up-to-date than these
notification listeners, because they are also not kept atomically in sync with
the DataTracker.View. It's difficult to reason about to even determine if this
is ever a problem.
> 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)
