-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
[exporterhelper] Fix race in concurrency check in batch sender leading to smaller batch sizes #9761
[exporterhelper] Fix race in concurrency check in batch sender leading to smaller batch sizes #9761
Conversation
Although activeRequests is atomic, it is possible for 2 arriving requests to both increment activeRequests, and when entering the critical section of bs.activeRequests.Load() >= bs.concurrencyLimit, both times it evaluates to true. The correct behavior should be that only the 2nd check is true. Remove the workaround in tests that bypassed the bug.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #9761 +/- ##
=======================================
Coverage 90.96% 90.96%
=======================================
Files 353 353
Lines 18626 18628 +2
=======================================
+ Hits 16943 16945 +2
Misses 1356 1356
Partials 327 327 ☔ View full report in Codecov by Sentry. |
Thanks for the fix, @carsonip! I'm curious to know more about your adoption of this API. Any feedback is welcome. |
@dmitryax not sure if you caught my latest edit. In my tests, with the bugfix, the behavior is slightly better, but there are still a lot of requests with just 1 item. It boils down to goroutine scheduling. It may require a bigger change in how queue sender and batch sender interact with each other to eliminate this issue.
I'm still experimenting with it. Batch sender blocking the |
Description:
Although activeRequests is atomic, it is possible for 2 arriving
requests to both increment activeRequests, and when entering the
critical section of bs.activeRequests.Load() >= bs.concurrencyLimit,
both times it evaluates to true. The correct behavior should be that
only the 2nd check is true.
Remove the workaround in tests that bypassed the bug.
Even with this change, the results are slightly better but still depend on goroutine scheduling.