cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-2419) Risk of counter over-count when recovering commit log
Date Mon, 02 May 2011 19:55:03 GMT


Jonathan Ellis updated CASSANDRA-2419:

    Attachment: 2419-v3.txt

v3 attached with some changes:

- SSTableMetadata removed; replayposition becomes a field in SSTable that is serialized w/
- RP is final and part of the SSTable constructor
- RP implements Comparable instead of a one-off resolve API; RP.getReplayPosition encapsulates
the find-replay-point logic
- RP moved to a top-level class and replaces CLContext

I'd like to make the metadata a json blob so we can extend it more easily, so I probably need
to re-introduce SSTM. Consider v3 a work in progress.

> Risk of counter over-count when recovering commit log
> -----------------------------------------------------
>                 Key: CASSANDRA-2419
>                 URL:
>             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,
>   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:

View raw message