New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KAFKA-14961: harden DefaultBackgroundThreadTest.testStartupAndTearDown test #13664
Conversation
…n test 1. Ensures that NPE are not thrown 2. Ensures that the background thread has been started to avoid flasky assertions failures on isRunning 3. Add a check that the thread is not running when closed
DefaultBackgroundThread backgroundThread = mockBackgroundThread(); | ||
backgroundThread.start(); | ||
assertTrue(backgroundThread.isRunning()); | ||
TestUtils.waitForCondition(backgroundThread::isRunning, "Failed awaiting for the background thread to be running"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will wait up to 15s, the default timeout. It should be good enough!
when(coordinatorManager.poll(anyLong())).thenReturn(mockPollCoordinatorResult()); | ||
when(commitManager.poll(anyLong())).thenReturn(mockPollCommitResult()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These stubs call where missing thus causing the NPE as indicated in the JIRA
@philipnee can you've a look? Thanks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fix!
backgroundThread.close(); | ||
assertFalse(backgroundThread.isRunning()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible that isRunning()
could take some time to return false
or is it guaranteed to be set by the time close()
is finished?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review @kirktrue
It is guaranteed that is running will be false when close()
is called:
kafka/clients/src/main/java/org/apache/kafka/clients/consumer/internals/DefaultBackgroundThread.java
Line 230 in 6c3e82f
this.running = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey thanks for the fix!
Thanks for the review @philipnee Do you know which committer we can tag for this to be reviewed and then merged by them? |
Hey @machi1990 - I'll get someone to review this. Thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks, @machi1990
I'm re-running the tests to see if we can get a green build. |
Thanks @vvcephei - I think this is a flaky test?
|
Thanks, @philipnee ! I agree it's probably flaky, but I don't see a ticket filed for it. We haven't been very strict recently about this, but I'm reluctant to just forge ahead at this point, given all the mailing list discussions about recent merges breaking the build because they didn't block on failing tests. Do you mind filing a ticket for this test, and then we can merge it? |
Thank you @vvcephei - https://issues.apache.org/jira/browse/KAFKA-14977 is filed 💘 |
Thanks @philipnee this should be good to be merged @vvcephei thanks! |
Thanks @philipnee @vvcephei for the review and merge! |
Committer Checklist (excluded from commit message)