[
https://issues.apache.org/jira/browse/CASSANDRA-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13580184#comment-13580184
]
Andrea Gazzarini commented on CASSANDRA-5074:
---------------------------------------------
It seems things are not so easy as described in my previous post. At the moment
there are two possible strategies: Leveled and SizeTiered compaction. Looking
at their code it seems that a disabled compaction should affect only
getNextBackgroundTask(...) and not getMaximalTask and getUserDefinedTask
(although this latter is not allowed in LeveredCompaction).
So the question is: what kind of compaction should run when I'm using a
NoCompactionStrategy and those two methods are invoked? SizeTiered, Leveled or
another that maybe will be implemented tomorrow and plugged in?
The obvious thing that comes in my mind is to think about NoCompactionStrategy
as a decorator; something like
> create column family X with compaction_strategy=NoCompactionStrategy AND
> compaction_strategy_options={delegate_strategy: LeveledCompactionStrategy,
> <other options>};
> create column family X with compaction_strategy=NoCompactionStrategy AND
> compaction_strategy_options={delegate_strategy: SizeTieredCompactionStrategy,
> <other options>};
So basically the getNextBackgroundTask will do nothing, effectively disabling
(minor) compaction, and the getMaximalTask and getUserDefinedTask will delegate
to a wrapped strategy that has been injected (the "delegate_strategy" option).
Now, I have a problem with the design of the XXXCompactionStrategy: in general
compaction strategies (this is valid both for SizeTiered and Leveled)
- have a lot of initialization code in their constructor, this makes hard to
use those strategies as an "inner" state of a decorator, I mean something like
: decoratee.init() --> decoratee.getMaximalTask() --> decoratee.close();
- receive a shared instance of ColumnFamilyStore and eventually (e.g.
SizeTieredCompactionStrategy) modify it; the initialization code assumes no
other compaction strategy are associated with the column family; so, based on
this assumption, the concrete strategy instance is free to modify the state of
its context (e.g. column family store)
All above makes difficult to implement a decorator pattern because the
decoratee instance will modify the same column family store of the decorator
(for example the SizeTieredCompactionStrategy modifies the min and max threshod
which are supposed to be 0 in case of compaction disabled).
For example, the ColumnFamilyStore has a method isCompactionDisabled that
basically checks if min or max threshols are set to 0. Now, when instantiating
the NoCompactionStrategy, one of the first thing that shoujld be done is
store.setCompactionThresholds(0,0);
after that, the wrapped instance should be initialized. Suppose for example
that the decoratee instance is a SizeTieredCompactionStrategy; creating a new
instance will immediately reset the previous thresholds to 4 and 32 because the
STCS has this code in its constructor:
cfs.setCompactionThresholds(cfs.metadata.getMinCompactionThreshold(),
cfs.metadata.getMaxCompactionThreshold());
Nothing, just to say that a simple NullObject is not enough, I'm trying to
solve that; once did, I'll submit a patch.
> Add an official way to disable compaction
> -----------------------------------------
>
> Key: CASSANDRA-5074
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5074
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
> Priority: Minor
> Fix For: 1.2.2
>
>
> We've traditionally used "min or max compaction threshold = 0" to disable
> compaction, but this isn't exactly intuitive and it's inconsistently
> implemented -- allowed from jmx, not allowed from cli.
--
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
