Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 5 Apr 2011 21:31:05 +0000 (UTC)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <99877186.36021.1302039065748.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <985022143.35908.1302036665806.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CASSANDRA-2419) Risk of counter over-count when
 recovering commit log
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jonathan Ellis commented on CASSANDRA-2419:
-------------------------------------------

to be clear: i believe if we do this we can drop CL header construct entirely.  instead, on startup we read last N bytes of each sstable file to get start-reply-at positions -- position for commitlog X and CF Y is max(start position) for sstables in X who were flushed during Y's tenure.

> Risk of counter over-count when recovering commit log
> -----------------------------------------------------
>
>                 Key: CASSANDRA-2419
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2419
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.8
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>              Labels: counters
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> When a memtable was flush, there is a small delay before the commit log replay position gets updated. If the node fails during this delay, all the updates of this memtable will be replay during commit log recovery and will end-up being over-counts.

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