Fix DefaultBatcher implementation to handle multiple producers.

[bogdandrutu]

Right now, if multiple producers are setup to talk to the DefaultBatcher it gets into a deadlock. Steps to reproduce remove all places where this issue is linked (force to allow only 1 producer).

[sfc-gh-sili]

@bogdandrutu Would you mind sharing some insight to this issue? I’ve tried reproducing the deadlock using what I believe to be a particularly adverse setup, but haven’t had any success:

#12920

• timeout is disabled
• numConsumer is set to 2, but at least 5 requests are needed to reach minThreashold.

If you have any thoughts on conditions that might reproduce it, I’d really appreciate it.

[sfc-gh-bdrutu]

Hey, the bug is fixed for memory corruption point. It is only useless at this point to have multiple goroutines since everything in the batcher happens under a lock.

[dmitryax]

@bogdandrutu Nice! I'll submit a PR to remove the hardcoded worker number = 1.

Hey, the bug is fixed for memory corruption point. It is only useless at this point to have multiple goroutines since everything in the batcher happens under a lock.

Not everything, just the batching itself. Sending the data out is still distributed over the workers, right? The batching part I guess will be addressed with the sharding that you proposed in #12473