[
https://issues.apache.org/jira/browse/CASSANDRA-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1417:
--------------------------------------
Attachment: 1417-v6.txt
v6 has RetryingScheduledThreadPoolExecutor.
unfortunate that you did not start with v2 as a base for subsequent revisions;
I had to re-apply those edits again.
> 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
>
> Attachments: 1417-cassandra-0.6-v3.txt, 1417-cassandra-0.6-v4.txt,
> 1417-cassandra-0.6-v5.txt, 1417-cassandra-0.6.txt, 1417-v2.txt, 1417-v6.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.
