[
https://issues.apache.org/jira/browse/CASSANDRA-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2419:
--------------------------------------
Attachment: 2419-v4.txt
I tried two ways of storing metadata as yaml -- first with the metadata as java
beans that were stored directly as yaml, and second half-manually serializing
to a yaml Map<String, Object> -- and both feel clunkier than just using the
version field to deal with adding things. (Especially when you need to do
version checks anyway when modifying things rather than just adding new fields.)
So, v4 is substantially the same as v3 but Descriptor version is bumped to g
and we use that instead of EOF to when reading RP. (Also, writeStatistics is
renamed to writeMetadata.)
> 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
