[
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)
