[
https://issues.apache.org/jira/browse/CASSANDRA-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew F. Dennis updated CASSANDRA-1417:
-----------------------------------------
Attachment: 1417-trunk-v9.txt
1417-cassandra-0.6-v9.txt
v9 attached
* adds JMX interface to save caches in trunk
* orders reads when loading row cache in token order
* adds tracker back into open calls so the key cache can be loaded
* sets KeyCacheSavePeriod to 1 hour in trunk
* migrates cache save periods in config-converter
> add cache save/load
> -------------------
>
> Key: CASSANDRA-1417
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1417
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Matthew F. Dennis
> Fix For: 0.6.6, 0.7.0
>
> Attachments: 1417-cassandra-0.6-v3.txt, 1417-cassandra-0.6-v4.txt,
> 1417-cassandra-0.6-v5.txt, 1417-cassandra-0.6-v7.txt,
> 1417-cassandra-0.6-v9.txt, 1417-cassandra-0.6.txt, 1417-trunk-v7.txt,
> 1417-trunk-v9.txt, 1417-v2.txt, 1417-v6.txt, 1417-v8.txt
>
>
> Since mixing 0.7 nodes with 0.6 is looking increasingly unlikely to be
> supported because of the deep changes to the Thrift API, we should allow
> saving out the 0.6 cache and loading it on startup so that we don't inflict
> the pain of an entire cluster of cold cache on upgraders.
> The cache format should just be a list of row keys. Loading it is as simple
> as calling getColumnFamily (with a zero-column predicate) on each row, for
> row cache.
> Key cache is more complicated, but only a little. First is that you have to
> de-duplicate the row keys from multiple sstables. (Saving which sstable
> version it's associated with is less useful, since that will be obsoleted by
> compaction.) Second is that we don't need to actually read any row data, we
> just need to go through the index locator part of the read path (getPosition).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
