lianetm commented on code in PR #16449:
URL: https://github.com/apache/kafka/pull/16449#discussion_r1665958301
##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/AsyncKafkaConsumer.java:
##########
@@ -1490,6 +1490,8 @@ public void unsubscribe() {
log.error("Failed while waiting for the unsubscribe event
to complete");
}
resetGroupMetadata();
+ } else {
Review Comment:
yeap, I really liked that idea when I shared it. We should only note that if
we take that path, we would have to end up calling the
`subcriptionState.unsubscribe` from the `ApplicationEventProcessor` where we
process(UnsubscribeEvent). We wouldn't be able to reuse the `MembershipMgr`
logic (which is part of what I had in mind when commenting on the jira),
because if there is no groupId we don't even have an instance of the
MembershipMgr.
Still, I like the idea because 1) simplifies the consumer.unsubscribe, 2)
all subscriptionState.unsubscribe calls are in the background thread associated
to the UnsubscribeEvent (directly if no groupId, indirectly if groupId present,
delegating on the membershipMgr). Makes sense?
--
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
