[
https://issues.apache.org/jira/browse/CASSANDRA-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-2420:
----------------------------------------
Attachment: 0001-Handle-the-row-cache-for-streamed-row.patch
There is a very simple patch for this issue. It consists in invalidating the
cache for each key we index. The downside is that this will invalidate all key
that gets repaired, but updating the cache (instead of invalidating) implies
reading on disk so doing this during the indexing or at the next read may not
matter much. In any case, this is better that the current situation and after
all .
I however attached a patch (against trunk for now) that 'do the right thing'
and will update the cache in the case of repair instead of invalidating. I
mentioned the first solution in case we consider that the 'right one' is too
disruptive for 0.7 for instance (not that the patch is very complicated).
Note that the patch fixes a tiny unrelated issue: the writeStat are not updated
during a write if the used cache has 'isPutCopying' (this could be fixed
separately).
> row cache / streaming aren't aware of each other
> ------------------------------------------------
>
> Key: CASSANDRA-2420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2420
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.6
> Reporter: Matthew F. Dennis
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 0.7.5
>
> Attachments: 0001-Handle-the-row-cache-for-streamed-row.patch
>
>
> SSTableWriter.Builder.build() takes tables that resulted from streaming,
> repair, bootstrapping, et cetera and builds the indexes and bloom filters
> before "adding" it so the current node is aware of it.
> However, if there is data present in the cache for a row that is also present
> in the streamed table the row cache can over shadow the data in the newly
> built table. In other words, until the row in row cache is removed from the
> cache (e.g. because it's pushed out because of size, the node is restarted,
> the cache is manually cleared) the data in the newly built table will never
> be returned to clients.
> The solution that seems most reasonable at this point is to have
> SSTableWriter.Builder.build() (or something below it) update the row cache if
> the row key in the table being built is also present in the cache.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
