lianetm commented on code in PR #15415:
URL: https://github.com/apache/kafka/pull/15415#discussion_r1499490700
##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/MembershipManagerImpl.java:
##########
@@ -564,7 +587,7 @@ public void transitionToJoining() {
*/
@Override
public CompletableFuture<Void> leaveGroup() {
- if (state == MemberState.UNSUBSCRIBED || state == MemberState.FATAL) {
+ if (state == MemberState.UNSUBSCRIBED || state == MemberState.FATAL ||
state == MemberState.STALE) {
Review Comment:
Good point, I think we could reuse it and I think it's a good direction. It
does require taking care of some other details: we need to make sure that when
the fencing callbacks complete, we don't blindly transition to joining (which
is the current shape). And also, when using `notInGroup` here for a no-op
leave, the fencing case is a bit different that then others, because we do need
to transition to UNSUBSCRIBED (other states remain unchanged if a leave group
call happens). All done.
This suggestion also makes me think about another tricky situation, that I
will leave to review separately if that's ok. I guess we could get a leave
group while fenced, then the user subscribes again, and the member will rejoin,
while the onPartitionsLost may have not completed yet. Only concern is that we
could get an assignment and end up running onPartitionsAssigned while the
onPartitionsLost is still running. That's not the behaviour in the old consumer
(callbacks execution blocks in the coordinator). I will file a jira to review
it better, as it would definitely complicate things more (as callbacks always
do).
--
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
