[
https://issues.apache.org/jira/browse/KAFKA-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361424#comment-14361424
]
Joel Koshy commented on KAFKA-2019:
-----------------------------------
When the round-robin assignor was done, I think we had considered this as well
- although it has been a while I cannot remember all the details, but I think
it did not actually do consistently well in simulations:
https://issues.apache.org/jira/browse/KAFKA-687?focusedCommentId=14077480&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14077480
This is a minor change, but potentially backwards incompatible. i.e., if you
were to roll out this change to a few consumer instances running in production
under a consumer group, they would run into rebalance failures (since the
global assignment results will be different between the instances that have
been upgraded and the ones that are not).
> RoundRobinAssignor clusters by consumer
> ---------------------------------------
>
> Key: KAFKA-2019
> URL: https://issues.apache.org/jira/browse/KAFKA-2019
> Project: Kafka
> Issue Type: Bug
> Components: consumer
> Reporter: Joseph Holsten
> Assignee: Neha Narkhede
> Priority: Minor
> Attachments: 0001-sort-consumer-thread-ids-by-hashcode.patch,
> KAFKA-2019.patch
>
>
> When rolling out a change today, I noticed that some of my consumers are
> "greedy", taking far more partitions than others.
> The cause is that the RoundRobinAssignor is using a list of ConsumerThreadIds
> sorted by toString, which is {{ "%s-%d".format(consumer, threadId)}}. This
> causes each consumer's threads to be adjacent to each other.
> One possible fix would be to define ConsumerThreadId.hashCode, and sort by
> that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
