Edoardo Comar created KAFKA-20619:
-------------------------------------

             Summary: 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


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)

Reply via email to