Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 25 Feb 2011 19:36:23 +0000 (UTC)
From: "Norman Maurer (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <805314806.282.1298662583248.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <23139618.295301294781206771.JavaMail.jira@thor>
Subject: [jira] Commented: (CASSANDRA-1967) commit log replay shouldn't end
 with a flush
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Norman Maurer commented on CASSANDRA-1967:
------------------------------------------

Maybe related to this.. I think if we keep the flush we should remove the commitlog file (segement) as soon as it was replayed. At the moment the file get deleted after all segements was replayed. At the moment it would be possible to have 19 segements replayed then on the 20th segement it throw an exception and so no file would get deleted. Which would lead to a complete replay of the previous 19 files on next start. 

> commit log replay shouldn't end with a flush
> --------------------------------------------
>
>                 Key: CASSANDRA-1967
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1967
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 0.3
>            Reporter: Robert Coli
>
> (Apologies in advance if there is some very compelling reason to flush after replay, of which I am not currently aware. ;D)
> Currently, when a node restarts, the following sequence occurs :
> a) commitlog is replayed
> b) any memtables resulting from a) are flushed 
> c) a new commitlog is opened, new memtables are switched in
> ... (other stuff happens)
> d) node starts taking traffic
> This has side effects, perhaps most seriously the potential of triggering compaction. As a node is likely to struggle performance-wise after restarting, triggering compaction at that time seems like something we might wish to avoid.
> I propose that the sequence be :
> a) commitlog is replayed
> b) a new commitlog is opened, new memtables are switched in 
> ... (other stuff happens)
> c) node starts taking traffic
> Looking through the relevant code, the only code that appears to depend on this flush is at src/java/org/apache/cassandra/db/commitlog/CommitLog.java:112 :
> "
>         // all old segments are recovered and deleted before CommitLog is instantiated.
>         // All we need to do is create a new one.
>         segments.add(new CommitLogSegment());
> "
> Presumably this code would have to be refactored to be aware of the currently open commitlog.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira