[
https://issues.apache.org/jira/browse/CASSANDRA-10341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14938982#comment-14938982
]
Paulo Motta commented on CASSANDRA-10341:
-----------------------------------------
I thought of 3 approaches to solve this problem:
1. After all sstables of a given table are received and added to CFS, iterate
over them and invalidate the keys.
Upside: ease of implementation.
Drawback: for large streams, this would mean reading all data from disk again
at a later point in time, which could add some overhead, like affecting the
page cache.
2. Instead of adding sstables to CFS after all sstables of a given table are
transferred, add each individual sstable to CFS when it is received, and
iterate over them to invalidate keys.
Upside: better than previous approach, since for moderate-sized sstables would
probably still be cached soon after it is received.
Drawback: Failed stream sessions would add data to the live system, even though
they did not complete successfully.
3. Implement a dependency invalidation mechanism on the caching service, so we
would pre-invalidate keys as they arrive, and complete the invalidation after
the stream session is complete (or drop the invalidation).
Upside: we would not need to re-read data to invalidate the keys.
Drawback: add complexity to caching service.
[~benedict] [~yukim] any thoughts on what would be the preferable approach?
> Streaming does not guarantee cache invalidation
> -----------------------------------------------
>
> Key: CASSANDRA-10341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10341
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Benedict
> Assignee: Paulo Motta
>
> Looking at the code, we attempt to invalidate the row cache for any rows we
> receive via streaming, however we invalidate them immediately, before the new
> data is available. So, if it is requested (which is likely if it is "hot") in
> the interval, it will be re-cached and not invalidated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
