[
https://issues.apache.org/jira/browse/CASSANDRA-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-8683:
---------------------------------------
Attachment: 0001-avoid-NPE-in-getPositionsForRanges.patch
I was wrong, the files do still exist
problem is in getPositionsForRanges - if last token is the actual last token in
the file (with early opening, it might not be), getPositions returns null
attaching patch to fix
> 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
>
> Attachments: 0001-avoid-NPE-in-getPositionsForRanges.patch
>
>
> 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)
