[
https://issues.apache.org/jira/browse/CASSANDRA-21474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18107498#comment-18107498
]
Stefan Miklosovic edited comment on CASSANDRA-21474 at 8/24/26 4:34 PM:
------------------------------------------------------------------------
We have replaced whole map-like implementation with Caffeine, that was the
primary design choice.
During the review there was manually added executor into Caffeine cache (1)
which was suspicious. I have checked what executors we use in other Caffeine
caches and it was always a custom executor we put there explicitly. I suggested
to copy this behavior - having a dedicated executor, otherwise it would use
ForkJoin pool or something like that to which Mick replied that yeah ... we do
not want that.
While we introduced it, now tests complain that we have introduced a thread we
should not in this test case (2) probably because it is not among
EXTRA_JDK_THREADS or similar. Since we have a bunch of tests extending this
class, we see failures everywhere (cca 200 hundreds).
I do not know if we should just add this among exceptions as it is done in case
of OPTIONAL_THREADS_WITH_SCHEMA, NON_DEFAULT_MEMTABLE_THREADS or
EXTRA_JDK_THREADS or approach this differently.
(1) https://github.com/apache/cassandra/pull/4993#discussion_r3749022244
(2)
https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/tools/OfflineToolUtils.java#L102
was (Author: smiklosovic):
We have replaced whole map-like implementation with Caffeine, that was the
primary design choice.
During the review there was manually added executor into Caffeine cache (2)
which was suspicious. I have checked what executors we use in other Caffeine
caches and it was always a custom executor we put there explicitly. I suggested
to copy this behavior - having a dedicated executor, otherwise it would use
ForkJoin pool or something like that to which Mick replied that yeah ... we do
not want that.
While we introduced it, now tests complain that we have introduced a thread we
should not in this test case (1) probably because it is not among
EXTRA_JDK_THREADS or similar. Since we have bunch of tests extend this class,
we see failures everywhere (cca 200 hundreds).
I do not know if we should just add this among exceptions as it is done in case
of OPTIONAL_THREADS_WITH_SCHEMA, NON_DEFAULT_MEMTABLE_THREADS or
EXTRA_JDK_THREADS or approach this differently.
(1)
https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/tools/OfflineToolUtils.java#L102
(2) https://github.com/apache/cassandra/pull/4993#discussion_r3749022244
> NoSpamLogger uses unbounded cache that could lead to memory exhaustion
> ----------------------------------------------------------------------
>
> Key: CASSANDRA-21474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21474
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Observability/Logging
> Reporter: Kathiresan Selvaraj
> Assignee: Viktoriia Kotovets
> Priority: Normal
> Fix For: 6.x, 7.x
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> The {{NoSpamLogger}} class maintains an unbounded cache of log statement keys
> without any eviction policy, which poses a memory leak risk.
> * Unbounded cache growth: The {{lastMessage}} map in {{NoSpamLogger.java}}
> uses a {{NonBlockingHashMap}} with no size limit or eviction policy.
> * When log messages contain dynamic content (e.g., query strings in
> tombstone warnings), each unique message creates a new cache entry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
