-
Notifications
You must be signed in to change notification settings - Fork 27
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
Fix concurrent map read and write in cache test #579
Fix concurrent map read and write in cache test #579
Conversation
This flaky test's root cause was that the StartCollecting method was locking the map to delete the expired item, but the test code could be writing to the map at the same time. By running the StartCollecting after writing the items to the map, we get rid of the possiblity of concurrent map read and write errors. Signed-off-by: Michail Resvanis <[email protected]>
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mresvanis The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
✅ Deploy Preview for kubernetes-sigs-kmm ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
/ok-to-test |
@mresvanis: The
Use In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
…kubernetes-sigs#789) This flaky test's root cause was that the StartCollecting method was locking the map to delete the expired item, but the test code could be writing to the map at the same time. By running the StartCollecting after writing the items to the map, we get rid of the possiblity of concurrent map read and write errors. Signed-off-by: Michail Resvanis <[email protected]> Upstream-Commit: f572c8e Co-authored-by: Michail Resvanis <[email protected]>
This flaky internal cache test's root cause was that the
StartCollecting
method was locking the map to delete the expired item, but the respective test code could be writing to the map at the same time without locking it. By running theStartCollecting
after the initial writing of the items to the map, we get rid of the possibility ofconcurrent map read and write
errors.Fixes #528