Proposal: Use per partition internal buffer about broadway_kafka

[josevalim]

Great job with the diagrams!

I think there may be a simpler solution to the routing. The PartitionDispatcher assumes somewhat even distribution of data, which is being violated here. So instead you can keep the buffer/queue per partition, then you store an index into which partition you must read from next, and you do so in cycles. You can do so with two changes:

1. Have map %{partition => queue}, which I believe you already do
2. Keep a ring to rate which partition to read next. This code can do it:

# Creates a new ring
defp new_ring([_ | _] = list), do: {list, []}

# Returns the {next_element_in_the_ring, ring}
defp next_ring({[], reversed}), do: next_partition({Enum.reverse(reversed), []})
defp next_ring({[head | tail], reversed}), do: {head, {tail, [head | reversed]}}

WDYT?

[slashmili]

Thanks!

I did kind use a lame way to make the ring 😬
here and here

I'd say still checking acks count is important. In my example all the data were processed in 50ms but not the case in real life. It's the checking the acks that make sure we don't overload the Dispatcher and able to join new generation on time

[josevalim]

I am worried about the checking acks count because it is hard for me to wrap around its impact under all possible scenarios. So I would like to start with a version without the acks count, improve that, and then consider the acks count. We can always add it later. :)

[slashmili]

Fair enough! I did remove the queue ack checking from my code and in the local env looks good enough to remedy the rebalancing as well. we can run it on prod when it's ready and monitor it.

I'll create a PR for queue change

[slashmili]

Fair enough! I did remove the queue from my code and in the local env looks good enough to remedy the rebalancing as well. we can run it on prod when it's ready and monitor it.

Sorry I meant I did remove checks for ack and rebalancing was done quickly

[anoskov]

@slashmili great work! Can you tell me please, with your feature should I set producers count for each partition for max concurrency or I should set it to 1?

[slashmili]

@slashmili great work! Can you tell me please, with your feature should I set producers count for each partition for max concurrency or I should set it to 1?

I haven't had a chance to work on the complete PR yet. When it's ready, you can choose whatever option suits you best.

[slashmili]

Fair enough! I did remove the queue ack checking from my code and in the local env looks good enough to remedy the rebalancing as well. we can run it on prod when it's ready and monitor it.

In the final implementation, it turns out that overloading PartitionDispatcher is still happening. I thought it solves the problem but there was a bug in my first code that the some demands were getting lost.