cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Eriksson (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-8683) Incremental repairs broken with early opening of compaction results
Date Mon, 26 Jan 2015 14:18:35 GMT
Marcus Eriksson created CASSANDRA-8683:
------------------------------------------

             Summary: Incremental repairs broken with early opening of compaction results
                 Key: CASSANDRA-8683
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8683
             Project: Cassandra
          Issue Type: Bug
            Reporter: Marcus Eriksson
            Assignee: Marcus Eriksson
             Fix For: 2.1.3


Incremental repairs holds a set of the sstables it started the repair on (we need to know
which sstables were actually validated to be able to anticompact them). This includes any
tmplink files that existed when the compaction started (if we wouldn't include those, we would
miss data since we move the start point of the existing non-tmplink files)

With CASSANDRA-6916 we swap out those instances with new ones (SSTR.cloneWithNewStart / SSTW.openEarly),
meaning that the underlying file can get deleted even though we hold a reference.

This causes the unit test error: http://cassci.datastax.com/job/trunk_utest/1330/testReport/junit/org.apache.cassandra.db.compaction/LeveledCompactionStrategyTest/testValidationMultipleSSTablePerLevel/

(note that it only fails on trunk though, in 2.1 we don't hold references to the repairing
files for non-incremental repairs, but the bug should exist in 2.1 as well)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message