[
https://issues.apache.org/jira/browse/CASSANDRA-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028334#comment-13028334
]
Jonathan Ellis commented on CASSANDRA-2419:
-------------------------------------------
bq. in CommitLog.java:recover(), was there a reason to create a new
List<ReplayPosition> positions instead of using cfPositions.values()
Nope. I'll fix that before commit.
Asked Paul Cannon to also review first though, since obviously we want to be
extra sure not to cause regressions here.
> 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
