[
https://issues.apache.org/jira/browse/CASSANDRA-11159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148650#comment-15148650
]
Sam Tunnicliffe commented on CASSANDRA-11159:
---------------------------------------------
bq. ColumnIndex needs to keep a list of memtables pending flush
I had suspected that might well be the case, the changes & test on your branch
LGTM.
I guess I might be tempted to mark {{getCurrentMemtable}} and
{{getPendingMemtables}} in {{ColumnIndex}} with {{@VisibleForTesting}}, but
that's pretty minor tbh.
> SASI indexes don't switch memtable on flush
> -------------------------------------------
>
> Key: CASSANDRA-11159
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11159
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Priority: Critical
> Fix For: 3.4
>
>
> SASI maintains its own in-memory structures for indexing the contents of a
> base Memtable. On flush, these are simply discarded & replaced with an new
> instance, whilst the on disk index is built as the base memtable is flushed
> to SSTables.
> SASIIndex implements INotificationHandler and this switching of the index
> memtable is triggered by receipt of a MemtableRenewedNotification. In the
> original SASI implementation, one of the necessary modifications to C* was to
> emit this notification from DataTracker::switchMemtable, but this was
> overlooked when porting to 3.0. The net result is that the index memtable is
> never switched out, which eventually leads to OOME.
> Simply applying the original modification isn't entirely appropriate though,
> as it creates a window where it's possible for the index memtable to have
> been switched, but the flushwriter is yet to finish writing the new index
> sstables. During this window, index entries will be missing and query results
> inaccurate.
> I propose leaving Tracker::switchMemtable as is, so that
> INotificationConsumers are only notified from there when truncating, but
> adding similar notifications in Tracker::replaceFlushed, to fire after the
> View is updated.
> I'm leaning toward re-using MemtableRenewedNotification for this as
> semantically I don't believe there's any meaningful difference between the
> flush and truncation cases here. If anyone has a compelling argument for a
> new notification type though to distinguish the two events, I'm open to hear
> it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
