[
https://issues.apache.org/jira/browse/CASSANDRA-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916618#action_12916618
]
Matthew F. Dennis commented on CASSANDRA-1417:
----------------------------------------------
v7 patches:
uses RetryingScheduledThreadPoolExecutor in both trunk and 0.6
moves saved caches to their own directory and changed names of saved cache
files (to prevent conflicts with index/db files)
adds config option for location of saved caches directory and creates it on
startup
changes 0.6 to write byte[] instead of string to 0.7 can read them
defaults keycache save period to 3600 seconds, turns rowcache save period off
changes default (when not specified) compaction and save cache priority to
Thread.MIN
more useful logging, less redundant logging
switched to using com.google.common.base.Function in 0.7 for savedCacheWriter
modified config-converter to convert SavedCacheDirectory (and noticed that I
missed the save_[key|row]_cache period)
modified config-converter to take location of old and new config as arguments
> 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 beta 2
>
> 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.txt,
> 1417-trunk-v7.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.
