-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[testbed] Fix loadgenerator race condition #32351
Conversation
Just realized that I misread the code and the fix will not work 🤦 . Putting it in draft until I figure out the correct fix. |
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.
@songy23 Thanks for the review. The previous fix was not totally correct so I have updated the fix to propagate the errors from |
ProviderSender based load generator had a race condition when used with Parallel option configured to a value greater than 1. The commit fixes the race condition by changing the behavior of how logging works w.r.t previously observed errors.
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.
Looks good to me, just one minor suggestion. Thanks for all of your work here, and helping me understand what's going on better! Really appreciate it!
@songy23 @crobert-1 Is there anything blocking here to get this merged? |
@atoulme Friendly ping, will you be able to review this whenever you have time and merge the PR if things look okay? |
@atoulme Apologies for the 2nd ping but would it be possible to get this merged this week? (AFAICS the test failures is unrelated to this PR) |
Description:
Fixes a race condition in testbed's default load generator (
ProviderSender
). The fix changes the behavior of how logging works for theProviderSender
. Before this PR, the code will try to log errors if the previous error is not the same and it would try to do this across goroutines. Now, each error will be logged if the previous error is not the same for each goroutine.Alternatively, we can also build a logger using bloom filter to try to log each error once though I am not sure if that would be required. This PR offers a quick fix while keeping the behavior reasonably close to the current behavior.
Closes #32326
Link to tracking Issue: #32326
Testing: Follow the steps in the tracking issue.
Documentation: Not required.