lianetm commented on code in PR #14690:
URL: https://github.com/apache/kafka/pull/14690#discussion_r1383599082
##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/MembershipManager.java:
##########
@@ -73,30 +84,55 @@ public interface MembershipManager {
/**
* @return Current assignment for the member.
*/
- ConsumerGroupHeartbeatResponseData.Assignment currentAssignment();
+ Set<TopicPartition> currentAssignment();
Review Comment:
I will share thoughts on this on our next sync with @dajac and you
@AndrewJSchofield, as this is interesting. Just for the record, I do agree that
spreading topic IDs is the right way forward, and we do have them now in the
assignment path, but I realized when exploring this suggestion that it is a
much bigger change if we move away from `TopicPartition`, and we're not ready
for it at this point (mainly tricky/ugly because not all paths support topicID
yet but most of them access/update the shared `subscriptionState` component and
`TopicPartition`)
At this point looks to me that we're better of making use of the topic IDs
kind of "on the side", like we're doing now in the `membershipManager`, that
keeps the assigned topicId/names but still uses the same `TopicPartition`. This
is the same approach followed by the `Fetch` and `Metadata` paths, that
introduced topic Ids in a similar "on the side" way.
There's interesting food for thought here anyway.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
