You are viewing a plain text version of this content. The canonical link for it is here.

Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2011/05/03 14:33:03 UTC

[jira] [Commented] (CASSANDRA-2419) Risk of counter over-count when recovering commit log

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

Sylvain Lebresne commented on CASSANDRA-2419:
---------------------------------------------

v4 looks good, I like those changes (note: I committed r1099037 to fix CFSTest, it had a test with hardcoded sstable filenames using version 'f' and thus was failing)

> 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 beta 1
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>              Labels: counters
>             Fix For: 0.8.0
>
>         Attachments: 0001-Record-CL-replay-infos-alongside-sstables-v2.patch, 0001-Record-and-use-sstable-replay-position.patch, 2419-v3.txt, 2419-v4.txt
>
>   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