[
https://issues.apache.org/jira/browse/CASSANDRA-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021023#comment-13021023
]
Sylvain Lebresne commented on CASSANDRA-2420:
---------------------------------------------
Committed to 0.8 and trunk.
Was should we do about 0.7 ? I realized that we do not differentiate between
the different reason for streaming in 0.7, so the simplest way to deal with
this would probably be to just blindly invalidate the cache. Sounds reasonable ?
> 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-v2.patch,
> 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
