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