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
In my experiments, the batch sender is producing inconsistent batch sizes which could be lower than desired due to goroutine scheduling even after #9761 . The scenario I usually run into is that given queue sender concurrency = batch sender concurrency limit = N, and they are all blocked on send, when the send eventually returns, activeRequest will first be set to N-1, then a new consumer goroutine comes in and increments the active request, then realize N-1+1 == concurrencyLimit, and will send off the request right away, causing an undesirably small request to be exported without batching.
I tried to fix it by resetting bs.activeRequests to 0 next to close(b.done). While it fixes for sendMergeBatch, it will not work for sendMergeSplitBatch since it may be exporting something outside of activeBatch. I assume there might be a way around this for merge split batch, but I'm not sure if it is worth the trouble and complexity to workaround unfavorable goroutine scheduling.
Steps to reproduce
Use batch sender with sending_queue num_consumers=100, send events to it.
What did you expect to see?
Batch sender consistently produces batch of size 100
What did you see instead?
Batch sender produces first batch of size 100, then most of the time size is 1.
@dmitryax question: what's the reason behind the concurrency check in the first place? If it is just to avoid meaningless waits when all goroutines are blocked by the same batch, then #9891 should fix it. If it is to avoid waits when all goroutines are blocked by different batches, I believe it is inherently vulnerable to the issue I mentioned in the bug report, and may need a different solution.
Describe the bug
From #8122 (comment)
In my experiments, the batch sender is producing inconsistent batch sizes which could be lower than desired due to goroutine scheduling even after #9761 . The scenario I usually run into is that given queue sender concurrency = batch sender concurrency limit = N, and they are all blocked on send, when the send eventually returns, activeRequest will first be set to N-1, then a new consumer goroutine comes in and increments the active request, then realize N-1+1 == concurrencyLimit, and will send off the request right away, causing an undesirably small request to be exported without batching.
I tried to fix it by resetting bs.activeRequests to 0 next to close(b.done). While it fixes for sendMergeBatch, it will not work for sendMergeSplitBatch since it may be exporting something outside of activeBatch. I assume there might be a way around this for merge split batch, but I'm not sure if it is worth the trouble and complexity to workaround unfavorable goroutine scheduling.
Steps to reproduce
Use batch sender with sending_queue num_consumers=100, send events to it.
What did you expect to see?
Batch sender consistently produces batch of size 100
What did you see instead?
Batch sender produces first batch of size 100, then most of the time size is 1.
What version did you use?
v0.97.0
What config did you use?
Environment
Linux Mint 21.3
Additional context
The text was updated successfully, but these errors were encountered: