cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Boudreault (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-8683) Ensure early reopening has no overlap with replaced files
Date Tue, 10 Feb 2015 14:42:26 GMT

     [ 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)

Mime
View raw message