You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Umbrella Issue] Many tests use Thread.sleep instead of synchronization primitives #1223
Many of our tests simply have a Thread.sleep(duration) when testing multi-threaded code. This is inherently flaky.
Instead we should use synchronization classes (generally Semaphore) to synchronized the tests which is both faster in the general case and not flaky in the extreme case.
@sarveshkaushal we'd welcome the help. In most cases the Thread.sleep(foo) is to wait for some other thread to complete it's work. Instead, we should create a Semaphore, then acquire() one or more permits for the executions we're waiting for, and then release() them in the Thread, then attempt to acquire() in the test thread to implement the wait.
The reason that Thread.sleep() is flaky is because in a CI/CD system like GitHub actions the machines can be massively overloaded, which leads to much longer delays than you might otherwise see when running tests, so the sleep(..) ends up not being long enough. You can always make the sleep longer, but that makes the tests run longer (and it's still flaky in extreme cases) so using synchronization primitives is (almost) always the right answer.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
// sleep 1s for notification distribution completing
Thread.sleep(1000);
assertTrue(expectAddHandler.isSatisfied());
assertTrue(expectUpdateHandler.isSatisfied());
assertTrue(expectDeleteHandler.isSatisfied());
}
I can create a semaphore and acquire it, blocking the main thread, but how will I release so that blocked main thread will continue the execution, I looked at many tests, facing similar problem in many of them.
Edit-
I cannot access ExecutorService instance variable which would have been useful over here, please suggest.
To avoid duplicating effort, I'm going to start working on the remaining items from the bottom of the list, beginning with extended/src/test/java/io/kubernetes/client/extended/event/EventCorrelatorTest.java.
Less time available than I anticipated, so I’m unassigning myself. I’m still planning to work on some of the tests, just without taking ownership of the issue.
Activity
brendandburns commentedon Sep 3, 2020
yue9944882 commentedon Sep 3, 2020
@brendandburns thanks for sorting out these potentially flaking tests.. will fix them later!
/assign
sarveshkaushal commentedon Sep 3, 2020
I would like to help :-)
brendandburns commentedon Sep 3, 2020
@sarveshkaushal we'd welcome the help. In most cases the
Thread.sleep(foo)is to wait for some other thread to complete it's work. Instead, we should create aSemaphore, thenacquire()one or more permits for the executions we're waiting for, and thenrelease()them in the Thread, then attempt toacquire()in the test thread to implement the wait.See an example PR #1219
The reason that
Thread.sleep()is flaky is because in a CI/CD system like GitHub actions the machines can be massively overloaded, which leads to much longer delays than you might otherwise see when running tests, so thesleep(..)ends up not being long enough. You can always make the sleep longer, but that makes the tests run longer (and it's still flaky in extreme cases) so using synchronization primitives is (almost) always the right answer.fejta-bot commentedon Dec 3, 2020
Issues go stale after 90d of inactivity.
Mark the issue as fresh with
/remove-lifecycle stale.Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with
/close.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot commentedon Jan 2, 2021
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with
/remove-lifecycle rotten.Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with
/close.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
brendandburns commentedon Jan 9, 2021
/lifecycle frozen
Priya103 commentedon Jan 20, 2021
If still available I would like to contribute
1 remaining item
Vyom-Yadav commentedon Aug 18, 2022
@brendandburns I have one doubt, I was working on
util/src/test/java/io/kubernetes/client/informer/cache/SharedProcessorTest.java, particularly on:java/util/src/test/java/io/kubernetes/client/informer/cache/SharedProcessorTest.java
Lines 27 to 60 in 536f725
I can create a semaphore and acquire it, blocking the main thread, but how will I release so that blocked main thread will continue the execution, I looked at many tests, facing similar problem in many of them.
Edit-
I cannot access
ExecutorServiceinstance variable which would have been useful over here, please suggest.vinayak912002 commentedon Aug 22, 2022
what are the things I need to learn in order to start contributiing to this project?
Vyom-Yadav commentedon Aug 27, 2022
@brendandburns ping
tmrpavan commentedon Apr 10, 2023
/assign
abhinavvrm2020 commentedon Oct 12, 2025
@brendandburns Is this issue still open. I would like to fix these tests.
test: replace Thread.sleep with sync primitives in tests
test: replace Thread.sleep with sync primitives in tests
test: replace remaining Thread.sleep calls with sync primitives
priyanshuvishwakarma273403 commentedon Jun 20, 2026
Hi @maintainer,
I would like to work on this issue. Could you please assign it to me?
flrnd commentedon Sep 28, 2026
Hey,
I see there are already PRs open for:
Thread.sleep()fromDefaultWorkQueueTest#4910Thread.sleep()from port forward test class #4911Thread.sleep()fromKubernetesReconcilerCreatorTest#4915To avoid duplicating effort, I'm going to start working on the remaining items from the bottom of the list, beginning with
extended/src/test/java/io/kubernetes/client/extended/event/EventCorrelatorTest.java./assign
flrnd commentedon Oct 5, 2026
Less time available than I anticipated, so I’m unassigning myself. I’m still planning to work on some of the tests, just without taking ownership of the issue.
/unassign