[
https://issues.apache.org/jira/browse/CASSANDRA-16261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17272466#comment-17272466
]
Ekaterina Dimitrova edited comment on CASSANDRA-16261 at 1/26/21, 10:23 PM:
----------------------------------------------------------------------------
Hi [~jjirsa],
As we talked on Slack, I agree with your point that clearing the warnings for
old branches, if it is done Is better to be more incremental. Thank you for
raising the topic as there is no strict policy on cleaning the code, the only
thing I know is that we try to do it while we work on patches and thus fully
clean it in time. Apologize for any inconvenience caused to anyone during merge.
[~maedhroz], [~adelapena] I just committed a ninja fix to all three branches to
move from NoSpamLogger to the normal logger at TRACE:
4d4218c553..44ca3d322d cassandra-3.0
a9ab7bde4e..11b07536a9 cassandra-3.11
186c731664..11789e0f3c trunk -> trunk
/CC [~tsteinmaurer]
was (Author: e.dimitrova):
Hi [~jjirsa],
As we talked on Slack, I agree with your point that clearing the warnings for
old branches if it is done Is better to be more incremental. Thank you for
raising the topic as there is no strict policy on cleaning the code, the only
thing I know is that we try to do it while we work on patches and thus fully
clean it in time. Apologize for any inconvenience caused to anyone during merge.
[~maedhroz], [~adelapena] I just committed a ninja fix to all three branches to
move from NoSpamLogger to the normal logger at TRACE:
4d4218c553..44ca3d322d cassandra-3.0
a9ab7bde4e..11b07536a9 cassandra-3.11
186c731664..11789e0f3c trunk -> trunk
/CC [~tsteinmaurer]
> Prevent unbounded number of flushing tasks
> ------------------------------------------
>
> Key: CASSANDRA-16261
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16261
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
> Reporter: Ekaterina Dimitrova
> Assignee: Ekaterina Dimitrova
> Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> The cleaner thread is not prevented from queueing an unbounded number of
> flushing tasks for memtables that are almost empty.
> This patch adds a mechanism to track the number of pending flushing
> tasks in the memtable cleaner. Above the maximum number (2x the flushing
> threads by default), only memtables using at least MCT memory will be
> flushed, where MCT stands for Memory Cleanup Threshold.
> This patch also fixes a possible problem tracking the memory marked as
> "reclaiming" in the memtable allocators and pool. Writes that complete
> only after a memtable has been scheduled for flushing, did not report
> their memory as reclaiming. Normally this should be a small value of no
> consequence, but if the flushing tasks are blocked for a long period,
> and there is a sufficient number of writes, or these writes use
> a sufficiently large quantity of memory, this would cause the memtable
> cleaning algorithm to schedule repeated flushing tasks because the used
> memory is always > reclaiming memory + MCT.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
