cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2420) row cache / streaming aren't aware of each other
Date Wed, 13 Apr 2011 16:07:05 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019400#comment-13019400
] 

Sylvain Lebresne commented on CASSANDRA-2420:
---------------------------------------------

bq. I would be more comfortable having LCR throw UnsupportedOperation if asked for full row,
since You Shouldn't Do That.

Updated patch defines getFullColumnFamily() only for AbstractCompactedRow. However I think
it would be a bad idea to fail in the Builder, so the Builder now simply invalidate the cache
if he is facing a big row (hence not fitting it in memory) and log a warning since if that
happens "you're doing it wrong".

I've also changed the switch case in updateCache.

> 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

Mime
View raw message