[ https://issues.apache.org/jira/browse/CASSANDRA-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Boudreault updated CASSANDRA-8683: --------------------------------------- Attachment: test.sh [~benedict] Can you try this simple one and let me know if you can reproduce the issue. I do see the message on each run. > 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, > system.log, test.sh > > > 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)