[PR] CASSANDRA-19597 - flush listeners SystemKeyspace CFS flushing blocked by unrelated keyspace flushing/co… [cassandra]

["smiklosovic (via GitHub)" <gi...@apache.org>]

smiklosovic opened a new pull request, #5247:
URL: https://github.com/apache/cassandra/pull/5247

   …mpaction
   
   There is a single post-flush thread, and each post-flush task used to wait on it for its own flush to finish. Since all tables shared that one queue, a slow flush of any table held up the flush futures of every other table - including the blocking flush of system.peers that StorageService.removeEndpoint performs on GossipStage, which stalls gossip long enough for nodes to be marked down (CASSANDRA-20607).
   
   Flush futures are now completed by noticing that a prefix of the table's own flushes has finished, using memtable flush listeners as introduced for Accord in CASSANDRA-20780: memtables carry an id that increases in creation order and can be notified once flushed, and each table tracks its memtables whose flush has not finished. A flush future completes once no memtable of its table up to its own is still unfinished, so it waits on nothing but that table's flushes.
   
   A memtable counts as finished only after its post-flush has discarded the flushed range of the commit log, so a completed flush future still guarantees that range is clean, as commit log segment recycling relies on. The post-flush work still runs on the single post-flush thread, which keeps commit log discards serial, but is only handed to it once its flush is done, so nothing on that thread waits any more. A failed flush counts as finished too, so it does not hold up the flushes after it.
   
   Thanks for sending a pull request! Here are some tips if you're new here:
    
    * Ensure you have added or run the [appropriate tests](https://cassandra.apache.org/_/development/testing.html) for your PR.
    * Be sure to keep the PR description updated to reflect all changes.
    * Write your PR title to summarize what this PR proposes.
    * If possible, provide a concise example to reproduce the issue for a faster review.
    * Read our [contributor guidelines](https://cassandra.apache.org/_/development/index.html)
    * If you're making a documentation change, see our [guide to documentation contribution](https://cassandra.apache.org/_/development/documentation.html)
    
   Commit messages should follow the following format:
   
   ```
   <One sentence description, usually Jira title or CHANGES.txt summary>
   
   <Optional lengthier description (context on patch)>
   
   patch by <Authors>; reviewed by <Reviewers> for CASSANDRA-#####
   
   Co-authored-by: Name1 <email1>
   Co-authored-by: Name2 <email2>
   
   ```
   
   The [Cassandra Jira](https://issues.apache.org/jira/projects/CASSANDRA/issues/)
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: pr-unsubscribe@cassandra.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: pr-unsubscribe@cassandra.apache.org
For additional commands, e-mail: pr-help@cassandra.apache.org