Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 18 Sep 2012 03:41:07 +1100 (NCT)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <1462354316.88390.1347900067829.JavaMail.jiratomcat@arcas>
In-Reply-To: 
 <1304877890.50717.1336675371481.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CASSANDRA-4237) Add back 0.8-style
 memtable_lifetime feature
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13457134#comment-13457134 ] 

Jonathan Ellis commented on CASSANDRA-4237:
-------------------------------------------

bq. There is expire check when flushed memtable is clean and reschedule another flush

Hmm...  is there a race here where if user manually calls force flush while it's expired, we get two scheduled tasks added?

Maybe just inlining a simple runnable instead of using forceFlush would be cleaner.  (We don't need to worry about indexes being dirty independently of the base memtable in this case, either.)

bq. 10sec brute force would work if memtable_flush_period is set longer (seconds or minutes). 

Good point.

bq. Here, you mean the period of brute force flush?

Yes.
                
> Add back 0.8-style memtable_lifetime feature
> --------------------------------------------
>
>                 Key: CASSANDRA-4237
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4237
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>    Affects Versions: 1.0.0
>            Reporter: Jonathan Ellis
>            Assignee: Yuki Morishita
>            Priority: Minor
>             Fix For: 1.2.0
>
>         Attachments: 4237.txt
>
>
> Back in 0.8 we had a memtable_lifetime_in_minutes setting.  We got rid of it in 1.0 when we added CASSANDRA-2427, which is a better way to  ensure flushing on low-activity memtables.
> However, at the same time we also added the ability to disable durable writes.  So it's entirely possible to configure a low-activity memtable, that isn't part of the commitlog.  So, we should add back a memtable lifetime setting.
> An additional motive is pointed out by http://www.fsl.cs.sunysb.edu/~pshetty/socc11-gtssl.pdf: if you have a *high* activity columnfamily, and don't require absolute durability, the commitlog is redundant if you are flushing faster than the commitlog sync period.  So, disabling durable writes but setting memtable lifetime to the same as the commitlog sync would be a reasonable optimization.
> Thus, when we add back memtable lifetime, I think we should measure it in seconds or possibly even milliseconds (to match commitlog_sync_period) rather than minutes.

--
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