So, what do you suggest to address the topic C with lesser traffic? Should
we create a separate StreamBuilder and build a separate topology for topic
C so we can configure number of threads as per our requirement for that
topic?
On Tue, Oct 6, 2020 at 10:27 PM Matthias J. Sax wrote:
> The
The current assignment would be "round robin". Ie, after all tasks are
created, we just take task-by-task and assign one to the threads one-by-one.
Note though, that the assignment algorithm might change at any point, so
you should not rely on it.
We are also not able to know if one topic has
I can confirm this was failing because I was setting
*source.consumer.auto.offset.reset:
“latest”*. Setting it back to *earliest* makes it work again.
This was working for me on 2.5.1 only because I didn't have my fix that
allows *source.consumer.auto.offset.reset: “latest”*. Override was not
Matthias,
I am just wondering how the tasks will be spread across threads in case I
have lesser threads than the number of partitions. Specifically taking my
use case, I have 3 inputs topics with 8 partitions each and I can configure
12 threads, so how below topics partitions will be distributed
