You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Greg Harris (Jira)" <ji...@apache.org> on 2022/11/16 22:50:00 UTC

[jira] [Updated] (KAFKA-14396) Flaky memory leak tests rely on System.gc for correctness

     [ https://issues.apache.org/jira/browse/KAFKA-14396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Greg Harris updated KAFKA-14396:
--------------------------------
    Labels: flaky-test  (was: )

> Flaky memory leak tests rely on System.gc for correctness
> ---------------------------------------------------------
>
>                 Key: KAFKA-14396
>                 URL: https://issues.apache.org/jira/browse/KAFKA-14396
>             Project: Kafka
>          Issue Type: Test
>            Reporter: Greg Harris
>            Priority: Minor
>              Labels: flaky-test
>
> There are a few tests which currently call System.gc to help verify that code running during a test does not leak memory. These tests are:
> * org.apache.kafka.common.memory.GarbageCollectedMemoryPoolTest#testBuffersGarbageCollected
> * org.apache.kafka.common.record.MemoryRecordsBuilderTest#testBuffersDereferencedOnClose
> * org.apache.kafka.streams.state.internals.ThreadCacheTest#cacheOverheadsSmallValues
> * org.apache.kafka.streams.state.internals.ThreadCacheTest#cacheOverheadsLargeValues
> Unfortunately the System.gc call is only an advisory call to the JVM, as documented:
> > When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.
> This means that the System.gc call may not have performed any garbage collection at all, and so tests which expect garbage collection to have happened will not always succeed. For example, a no-op is an implementation of the System.gc method which would fulfill the method contract.
> To reproduce this class of failures:
> 1. Comment out the System.gc calls
> 2. Run the test
> We should try to find an alternative method of verifying that these components do not have memory leaks that does not rely on the implementation-specific behavior of the containing JVM runtime. For example, verifying that buffers have been closed may be a proxy for the literal memory references being released and garbage collected.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)