[
https://issues.apache.org/jira/browse/CASSANDRA-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13596970#comment-13596970
]
Sylvain Lebresne commented on CASSANDRA-3430:
---------------------------------------------
It occurred to me that "Major compactions, cleanup, scrub, and upgradesstables
will interrupt any in-progress compactions when invoked" also include
validation compaction (unless I'm missing something). Which bother me a bit
because:
# breaking a repair is often pretty painful to users, so we shouldn't make it
too easy to break validation compaction by mistake.
# we don't handle that very well in repair. I.e, the repair for which we stop
the validation compaction will just hang forever.
# this is not really necesseray. Validation compaction are read-only and in
particular don't mark sstables as compacting.
So I think we should ignore validation compaction in runWithCompactionDisabled
(I think it's fine ignoring them in interruptCompactionFor directly).
bq. index.truncate goes through CFS.truncate and runWithCompactionsDisabled
again
Hum, I'm not seeing that. In {{index.truncate}} in the truncate runnable,
{{index}} is a {{SecondaryIndex}} object, not a CFS. And as far as I can tell,
that truncate is defined in AbstractSimplePerColumnSecondaryIndex and only call
CFS.discardSSTables (which doesn't call CFS.truncate back that I can see).
In fact, we don't want indexes to go though the whole CFS.truncate directly,
because this is what decides of truncateAt and we want index to use the same
truncateAt that their parent.
bq. My reasoning here was that for DROP CF/KS, we don't actually need to wait
for the compactions to be interrupted
Truth being told, I was thinking of user trigger interruption, feeling that
having them block until the compaction are indeed interrupted was making more
sense. But looking more closely, that's not using interruptCompactionFor.
That being said, for DROP, even if waiting is not necessary, it won't be
harmful either and the wait will be short enough that it won't change the user
experience measurably. So really, I just felt it made more sense for
encapsulation to have the wait in interruptCompactionFor, but that's not a big
deal.
Though now that you mention drop, I wonder if having the drop methods use
runWithCompactionsDisabled wouldn't simplify things a bit. It would allow
removing a bunch of cfs.isValid() check in CompactionManager/DataTracker (the
only one to keep would be for flushing). And perhaps more importantly, knowing
no compaction happens during a drop makes things easier to reason about.
Anyway, probably for a followup ticket in any case.
> Break Big Compaction Lock apart
> -------------------------------
>
> Key: CASSANDRA-3430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3430
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Labels: compaction
> Fix For: 2.0
>
> Attachments: 3430-1.0.txt, 3430-1.1.txt, 3430-v2.txt, 3430-v3.txt
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
