[
https://issues.apache.org/jira/browse/CASSANDRA-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028315#comment-13028315
]
Sylvain Lebresne commented on CASSANDRA-2419:
---------------------------------------------
Minor nitpick: in CommitLog.java:recover(), was there a reason to create a new
List<ReplayPosition> positions instead of using cfPositions.values() ?
but other than that, +1 on v6.
> 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 beta 2
>
> Attachments: 0001-Record-CL-replay-infos-alongside-sstables-v2.patch,
> 0001-Record-and-use-sstable-replay-position.patch, 2419-v3.txt, 2419-v4.txt,
> 2419-v6.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
