[ https://issues.apache.org/jira/browse/KAFKA-17103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868458#comment-17868458 ]
zhengke zhou commented on KAFKA-17103: -------------------------------------- Hi [~gharris1727] I would like to try this. > MockClient tight loops when no metadata is present in KafkaProducerTest > ----------------------------------------------------------------------- > > Key: KAFKA-17103 > URL: https://issues.apache.org/jira/browse/KAFKA-17103 > Project: Kafka > Issue Type: Test > Components: clients > Reporter: Greg Harris > Priority: Minor > Labels: newbie > > MockClient can throw this exception: > {noformat} > [2024-07-09 13:19:33,574] ERROR [Producer clientId=producer-1] Uncaught error > in kafka producer I/O thread: > (org.apache.kafka.clients.producer.internals.Sender:253) > java.lang.IllegalStateException: No previous metadata update to use > at > org.apache.kafka.clients.MockClient$DefaultMockMetadataUpdater.updateWithCurrentMetadata(MockClient.java:700) > at org.apache.kafka.clients.MockClient.poll(MockClient.java:323) > at > org.apache.kafka.clients.producer.internals.Sender.runOnce(Sender.java:349) > at org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:251) > at java.base/java.lang.Thread.run(Thread.java:829){noformat} > This happens whenever the MockClient.DefaultMockMetadataUpdater#lastUpdate > variable is null, which is the case whenever there has not been any mock > metadata update. > In practice, this appears to happen in > KafkaProducerTest#testTopicExpiryInMetadata, > KafkaProducerTest#testTopicRefreshInMetadata, > KafkaProducerTest#testTopicNotExistingInMetadata. These three tests also use > busy-waiting to have another thread wait for the metadata update request and > then provide the metadata update. > We should find some mechanism to allow mocking these metadata updates that > avoids this busy waiting/tight looping pattern, as it introduces an > opportunity for nondeterminism and wastes CPU cycles. > The solution should remove any usage of Thread.sleep/Utils.sleep/Time.SYSTEM. > Ideally the solution wouldn't require an additional test thread, but this is > optional. -- This message was sent by Atlassian Jira (v8.20.10#820010)