[
https://issues.apache.org/jira/browse/CASSANDRA-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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/ statistics
- 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: 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
>
> 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
