[
https://issues.apache.org/jira/browse/KAFKA-10068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17120028#comment-17120028
]
Matthias J. Sax commented on KAFKA-10068:
-----------------------------------------
I see what you are saying, but it seems strange to apply a different timeout
internally? Especially if it would be hard-coded and non-configurable? The
rebalance protocol has already a built-in timeout if something goes wrong
during assignment. If we think that piggy-packing this timeout onto
`max.poll.interval.ms` is not the right thing to do, it might be better to just
add a new consumer config to allow users to bound the time spent in `assign()`
explicitly? It seems like a hack to just add a non-configurable timeout to the
Kafka Streams specific PartitionAssignor.
> Verify HighAvailabilityTaskAssignor performance with large clusters and
> topologies
> ----------------------------------------------------------------------------------
>
> Key: KAFKA-10068
> URL: https://issues.apache.org/jira/browse/KAFKA-10068
> Project: Kafka
> Issue Type: Task
> Components: streams
> Affects Versions: 2.6.0
> Reporter: John Roesler
> Priority: Blocker
>
> While reviewing [https://github.com/apache/kafka/pull/8668/files,] I realized
> that we should have a similar test to make sure that the new task assignor
> completes well within the default assignment deadline. 30 seconds is a good
> upper bound.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
