[
https://issues.apache.org/jira/browse/CASSANDRA-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13209048#comment-13209048
]
Peter Schuller commented on CASSANDRA-3921:
-------------------------------------------
With a typical workload, not evicting it would just fail to "optimize" - you
have to wait for the data to get dropped out of cache.
But if you do have a use-case where you have a lot of requests to non-existent
data, this could "silently" render the row caches almost useless in a way that
is very hard to detect. Suppose you have rows with a hot set where you want
caching, but the data is made up of "churning" columns (insertions/deletions;
the set of columns constantly But, the "damaged" is limited to the ratio of
requests for empty rows vs. other requests, and is less prominent the bigger
the average requested row in relation to the size of a tombstone.
The above should be true if the rows in cache only contain the tombstones.
But consider a use-case where you have rows (hot) that gets constantly updated
with insertion/deletion (let's say it has 1-5 columns at any point in time,
with columns constantly "churned"). How you have something which is hot in
cache due to reads (for the ones in hot set), data being over-written, and the
per-row average size increasing over time. Cache locality becomes worse and
worse and no one can see why, and a restart magically fixes it. This should
hold true as long as row cache entries aren't entirely re-read on writes, which
would in part defeat the purpose of caching (but I realize now I'm not sure
what we do here).
> Compaction doesn't clear out expired tombstones from SerializingCache
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-3921
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3921
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8.0
> Reporter: Jonathan Ellis
> Priority: Minor
> Fix For: 1.1.0
>
>
> Compaction calls removeDeletedInCache, which looks like this:
> {code}
> . public void removeDeletedInCache(DecoratedKey key)
> {
> ColumnFamily cachedRow = cfs.getRawCachedRow(key);
> if (cachedRow != null)
> ColumnFamilyStore.removeDeleted(cachedRow, gcBefore);
> }
> {code}
> For the SerializingCache, this means it calls removeDeleted on a temporary,
> deserialized copy, which leaves the cache contents unaffected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
