[ 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)