[
https://issues.apache.org/jira/browse/CASSANDRA-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12906540#action_12906540
]
Jonathan Ellis commented on CASSANDRA-1417:
-------------------------------------------
comments on patch:
- if you're going to organize imports, follow the order on
http://wiki.apache.org/cassandra/CodeStyle. also, looks like unused classes
like crypto.Data are being added
- we don't want to add a setting for loading cache on startup; if a cache is
present, it should be loaded
- we DO want a setting for how often to save cache (default should be: not at
all)
- cache saving should be done at compaction priority. may mean you need to
use an executor instead of a timer to get that level of control
- tmp cleanup should be in CFS constructor (0.6) / scrubDataDirectories (0.7),
not CassandraDaemon. similarly, loadRowCache should probably be called by CFS
constructor
- we only care about cache keys during save, so getEntrySet should be getKeys
- avoid the temptation to mix unrelated refactoring like the CFMetaData and DD
changes here into patches like this (this is where git comes in handy, you can
easilysave them off for separate review later)
- SavedCacheReader is a class with no fields, should probably just be a static
method somewhere (SSTable?). also, should return a new set rather than taking
one as parameter
- instead of making CacheWriter abstract, it would be cleaner to make the key
extractor an interface and have the CacheWriter take an instance of that (i
believe guava Converter interface would work here)
- should respect configured cache size and if saved cache is larger, should
log at info and oad as much as there is room for
> 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.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.
