cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrea Gazzarini (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5074) Add an official way to disable compaction
Date Sun, 17 Feb 2013 13:51:13 GMT

    [ 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

Mime
View raw message