Repository navigation
KAFKA-21017: Deflake ConsumerGroupCommandSaslAuthenticationTest - #23154
AndrewJSchofield merged 2 commits into
Conversation
…during group-visibility wait ClassicKafkaConsumer has no background thread, so poll() is what drives JoinGroup and SyncGroup for the classic group protocol. In testConsumerGroupServiceWithAuthenticationSuccess, the second waitForCondition checked group visibility but never called poll() again. If the handshake wasn't finished after the first successful poll, nothing pushed it forward, and the test timed out under load. This keeps the two waitForCondition blocks separate, so the auth-failure and missing-group-visibility messages stay distinguishable, and just adds poll() to the second one. Verified with the test class run 30 times with the fix (all green), 60 times reverted under a warm daemon (all green, does not reproduce the flake), and 30 times reverted under artificial CPU load (4/30 red, matching the ~10% rate reported before this change). Co-Authored-By: Claude Sonnet 5 <[email protected]>
github-actions
Bot
added
triage
|
LGTM |
AndrewJSchofield
left a comment
AndrewJSchofield
left a comment
There was a problem hiding this comment.
Thanks for the PR. I would prefer this to be refactored to use a similar pattern to ListConsumerGroupTest with an executor polling until the consumer is closed.
Use ConsumerGroupCommandTestUtils.buildConsumers like ListConsumerGroupTest so the classic protocol consumer keeps polling JoinGroup/SyncGroup on a background thread until the test closes it. Signed-off-by: Stan Shih <[email protected]> Co-authored-by: Cursor <[email protected]>
|
Thanks Andrew. I switched the success path to Pushed as 827a8a6. I did not re-run the cluster test on this box after the refactor (Windows load); happy to retrigger CI here. |
|
Hi @stantheman0128, KAFKA-21017 has been created for this flaky test, and I’m currently assigned to the issue. Also I verified the latest change locally by repeating |
stantheman0128
changed the title
|
Thanks. Title and description now match KAFKA-21017 and the I did not re-run the cluster test here after that refactor. Your 300 repeats of |
…he#23154) ClassicKafkaConsumer has no background thread, so poll() is what drives JoinGroup and SyncGroup for the classic group protocol. In testConsumerGroupServiceWithAuthenticationSuccess, the second waitForCondition checked group visibility but never called poll() again. If the handshake was not finished after the first successful poll, nothing pushed it forward, and the test timed out under load. Andrew asked to match ListConsumerGroupTest: an executor that keeps polling until the consumer is closed. The success path now uses ConsumerGroupCommandTestUtils.buildConsumers, so the classic consumer keeps polling JoinGroup/SyncGroup on a background thread until the test closes it. The two waitForCondition blocks stay separate so the auth-failure and missing-group-visibility messages stay distinguishable. Fixes KAFKA-21017. Verified: - First poll() patch: class run 30 times (all green); 60 times reverted under a warm daemon (all green); 30 times reverted under artificial CPU load (4/30 red). - After the buildConsumers refactor I did not re-run the cluster test on this Windows box. dino2895 repeated testConsumerGroupServiceWithAuthenticationSuccessWithClassicGroupProtocol 300 times with -Pkafka.cluster.test.repeat=300; all 300 passed. Co-Authored-By: Claude Sonnet 5 <[email protected]> Reviewers: Uros (github:uros-b), YANG-SYUAN CHOU <[email protected]>, Andrew Schofield <[email protected]> --------- Signed-off-by: Stan Shih <[email protected]> Co-authored-by: stantheman0128 <[email protected]> Co-authored-by: Claude Sonnet 5 <[email protected]> Co-authored-by: Cursor <[email protected]>
ClassicKafkaConsumer has no background thread, so poll() is what drives
JoinGroup and SyncGroup for the classic group protocol. In
testConsumerGroupServiceWithAuthenticationSuccess, the second
waitForCondition checked group visibility but never called poll() again.
If the handshake was not finished after the first successful poll,
nothing pushed it forward, and the test timed out under load.
Andrew asked to match ListConsumerGroupTest: an executor that keeps
polling until the consumer is closed. The success path now uses
ConsumerGroupCommandTestUtils.buildConsumers, so the classic consumer
keeps polling JoinGroup/SyncGroup on a background thread until the test
closes it. The two waitForCondition blocks stay separate so the
auth-failure and missing-group-visibility messages stay distinguishable.
Fixes KAFKA-21017.
Verified:
under a warm daemon (all green); 30 times reverted under artificial CPU
load (4/30 red).
this Windows box. dino2895 repeated
testConsumerGroupServiceWithAuthenticationSuccessWithClassicGroupProtocol
300 times with -Pkafka.cluster.test.repeat=300; all 300 passed.
Co-Authored-By: Claude Sonnet 5 [email protected]
Reviewers: Uros (github:uros-b), YANG-SYUAN CHOU [email protected],
Andrew Schofield [email protected]