[ https://issues.apache.org/jira/browse/KAFKA-8332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835206#comment-16835206 ]
Boyang Chen commented on KAFKA-8332: ------------------------------------ Thanks for the JIRA. I think there is an ongoing PR here: [https://github.com/apache/kafka/pull/6626] > Regression in handling of JoinGroupRequest disallows deterministic protocol > selection based on order of preference > ------------------------------------------------------------------------------------------------------------------ > > Key: KAFKA-8332 > URL: https://issues.apache.org/jira/browse/KAFKA-8332 > Project: Kafka > Issue Type: Bug > Components: core > Reporter: Konstantine Karantasis > Assignee: Konstantine Karantasis > Priority: Blocker > > When a group of Kafka clients includes more than one embedded protocol in its > {{JoinGroupRequest}} along with its metadata, the group membership protocol > defines that the protocol which is supported by all the members of a group is > selected, and if more than one protocols are supported by all the members the > protocol is selected based on the order of preference as defined in the > {{JoinGroupRequest}}. > A recent change from type {{List}} to type {{Set}} for storing the set of > supported embedded protocols in the {{JoinGroupRequest}} combined with the > old type of handling with implicit types in the scala code, has introduced > non-determinism in the selection of the embedded protocol by the > {{GroupCoordinator}}, even though the underlying type of the Set in use is a > variant of LinkedHashSet (it respects order). > The relevant code is: > {code:java} > // KafkaApis.scala > val protocols = joinGroupRequest.data().protocols().asScala.map(protocol => > (protocol.name, protocol.metadata)).toList > {code} > -- This message was sent by Atlassian JIRA (v7.6.3#76005)