[
https://issues.apache.org/jira/browse/CASSANDRA-19597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18125456#comment-18125456
]
Stefan Miklosovic edited comment on CASSANDRA-19597 at 10/9/26 9:36 AM:
------------------------------------------------------------------------
In case of the backport, what do we want?
1. SystemKeyspace flushes only
Port listeners, increasing memtable ids and the prefix check;
SystemKeyspace.forceBlockingFlush waits on the prefix being flushed instead of
the post-flush queue. The fallback waits on the same table's older memtable,
never the global queue. Fixes the 20607 gossip stall; other tables keep today's
behaviour.
2. All flush futures
Every forceFlush future completes on prefix-flushed notification. The most
complete, but futures would complete before commit log cleanup, so segment
recycling would have to change too. Biggest semantic change.
was (Author: smiklosovic):
In case of the backport, what do we want?
1. SystemKeyspace flushes only
Port listeners, increasing memtable ids and the prefix check;
SystemKeyspace.forceBlockingFlush waits on the prefix being flushed instead of
the post-flush queue. The fallback waits on the same table's older memtable,
never the global queue. Fixes the 20607 gossip stall; other tables keep today's
behaviour.
2. All flush futures
Every forceFlush future completes on prefix-flushed notification. The most
complete, but futures would complete before commit log cleanup, so segment
recycling would have to change too. Biggest semantic change.
3. Literal port only
Port exactly what 6.0 has, including the fallback to the global queue, and wire
it to nothing.
> SystemKeyspace CFS flushing blocked by unrelated keyspace flushing/compaction
> -----------------------------------------------------------------------------
>
> Key: CASSANDRA-19597
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19597
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Local/Memtable
> Reporter: Ariel Weisberg
> Assignee: Ariel Weisberg
> Priority: Normal
> Attachments: ci_summary.html
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> There is a single post flush thread and that thread processes tasks in order
> and one of those tasks can be a memtable flush for an unrelated keyspace/cfs,
> and that memtable flush can be blocked by slow IntervalTree building and
> racing with compactors to try and build an interval tree.
> Unless there is a requirement for ordering we probably want to loosen this to
> the actual ordering requirement so that problems in one keyspace can’t effect
> another.
> SystemKeyspace and Gossip in particular cause lots of weird problems like
> nodes marking each other down because Gossip can’t process nodes being
> removed (blocking flush each time in SystemKeyspace.removeNode)
> A very simple fix here might be to queue the post flush task at the same time
> as the flush in a per CFS queue, and then submit the task only once the flush
> is completed.
> If flushes complete out of order the queue will still ensure their
> completions are processed in order.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
