Greg Harris created KAFKA-14396:
-----------------------------------
Summary: 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
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)
