[
https://issues.apache.org/jira/browse/CASSANDRA-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14312407#comment-14312407
]
Alan Boudreault commented on CASSANDRA-8683:
--------------------------------------------
[~benedict] When using your branch, I'm getting this message when running my
tests and doing a cleanup:
{code}
Aborted cleaning up atleast one column family in keyspace r1, check server logs
for more information.
Aborted cleaning up atleast one column family in keyspace r1, check server logs
for more information.
Aborted cleaning up atleast one column family in keyspace r1, check server logs
for more information.
{code}
I can't get this outside of your branch. I'm not sure if this is an error or
something expected with your changes. There are no errors in the logs. I only
see this:
{code}
WARN [RMI TCP Connection(24)-127.0.0.1] 2015-02-09 10:56:10,282
ColumnFamilyStore.java:2587 - Unable to cancel in-progress compactions for
standard1. Perhaps there is an unusually large row in progress somewhere, or
the system is simply overloaded.
INFO [RMI TCP Connection(24)-127.0.0.1] 2015-02-09 10:56:10,282
CompactionManager.java:255 - Aborting operation on r1.standard1 after failing
to interrupt other compaction operations
INFO [RMI TCP Connection(24)-127.0.0.1] 2015-02-09 10:56:10,282
CompactionManager.java:260 - No sstables for r1.Counter3
INFO [RMI TCP Connection(24)-127.0.0.1] 2015-02-09 10:56:10,285
CompactionManager.java:260 - No sstables for system_traces.sessions
INFO [RMI TCP Connection(24)-127.0.0.1] 2015-02-09 10:56:10,285
CompactionManager.java:260 - No sstables for system_traces.events
WARN [RMI TCP Connection(27)-127.0.0.1] 2015-02-09 10:59:13,550
ColumnFamilyStore.java:2587 - Unable to cancel in-progress compactions for
standard1. Perhaps there is an unusually large row in progress somewhere, or
the system is simply overloaded.
{code}
Any hint about this? Should I go further in the issue and produce a minimal
test case to reproduce this message?
> 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)
