[
https://issues.apache.org/jira/browse/KAFKA-20619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edoardo Comar reassigned KAFKA-20619:
-------------------------------------
Assignee: Edoardo Comar
> ClusterTests may report Thread leak detected: Cleaner-0, Cleaner-1
> ------------------------------------------------------------------
>
> Key: KAFKA-20619
> URL: https://issues.apache.org/jira/browse/KAFKA-20619
> Project: Kafka
> Issue Type: Bug
> Components: unit tests
> Reporter: Edoardo Comar
> Assignee: Edoardo Comar
> Priority: Major
>
> Running in today's trunk (commit
> 89f3888c8718da91967badef560cf34ebe8e09ed)
> A test like
> ./gradlew clean client:clients-integration-tests:test --tests
> SocketServerMemoryPoolTest
> I get consistently
> testProduceRequestWithUnsupportedVersion [1] Type=Raft-Combined,
> MetadataVersion=4.4-IV0,BrokerSecurityProtocol=PLAINTEXT,BrokerListenerName=ListenerName(EXTERNAL),ControllerSecurityProtocol=PLAINTEXT,ControllerListenerName=ListenerName(CONTROLLER)
> FAILED
> org.opentest4j.AssertionFailedError: Thread leak detected: Cleaner-0,
> Cleaner-1 ==> expected: <true> but was: <false>
> at
> app//org.apache.kafka.common.test.junit.ClusterTestExtensions.afterEach(ClusterTestExtensions.java:184)
> at [email protected]/java.util.Optional.ifPresent(Optional.java:178)
> Which appears to be due to (Claude's report)
> Root cause — Cleaner-0 / Cleaner-1 are JDK-internal daemon threads created
> lazily by jdk.internal.ref.CleanerImpl (group: InnocuousThreadGroup). They're
> not
> application threads; they're spawned by JDK code for native resource
> cleanup (e.g. direct ByteBuffer deallocation) and live in the
> InnocuousThreadGroup. The
> ClusterTestExtensions thread-leak detector doesn't currently skip them, so
> it flags them as leaks.
> Why now — they're triggered the first time the broker happens to allocate
> enough direct-buffer-backed objects whose cleanup uses
> jdk.internal.ref.CleanerFactory. The testRequestWithUnsupportedVersion path
> goes through processChannelException which logs a full stack trace via log4j2
> —
> log4j2's formatting / reflective stack walk can be what causes the JDK to
> spin up these cleaners on first use. The corrupt-body test runs second, so by
> beforeEach the cleaners already exist and aren't reported as "new".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
