Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Sun, 17 Feb 2013 13:51:13 +0000 (UTC)
From: "Andrea Gazzarini (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12624486.1355847201519.299170.1361109073787@arcas>
In-Reply-To: <JIRA.12624486.1355847201519@arcas>
References: <JIRA.12624486.1355847201519@arcas>
Subject: [jira] [Commented] (CASSANDRA-5074) Add an official way to disable
 compaction
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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