-
Notifications
You must be signed in to change notification settings - Fork 14.9k
KAFKA-13072: Make RemoveMembersFromConsumerGroupHandler unmap for COORDINATOR_NOT_AVAILABLE error #11035
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@dajac , please take a look. Thanks. |
...ain/java/org/apache/kafka/clients/admin/internals/RemoveMembersFromConsumerGroupHandler.java
Show resolved
Hide resolved
| String memberId = memberResponse.memberId(); | ||
|
|
||
| if (memberError != Errors.NONE) { | ||
| handleMemberError(groupId, memberId, memberError, groupsToUnmap, groupsToRetry); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this really necessary? It seems that group level errors as always retuned as top level error in the response. Do you confirm?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the question. I checked broker code, and confirmed that all member response only contain member level errors, not group level or coordinator level. I remove it. Thanks.
dajac
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@showuon Thanks. I left a few more comments.
| } | ||
| return new ApiResult<>(completed, failed, unmapped); | ||
|
|
||
| if (groupsToUnmap.isEmpty() && groupsToRetry.isEmpty()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not seem necessary as we always expect the top level error. Would it make sense to handle it like we did here: https://github.com/apache/kafka/pull/11019/files#diff-e7eafbafe0b75099d0c8b4083c03c653d57245ef7b0fcfae7b9ccd258a9024e3R117?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree! Updated!
|
|
||
| memberErrors.put(new MemberIdentity() | ||
| .setMemberId(memberResponse.memberId()) | ||
| .setMemberId(memberId) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: We could revert this change as it does not bring much.
| .setMemberId(memberId) | ||
| .setGroupInstanceId(memberResponse.groupInstanceId()), | ||
| Errors.forCode(memberResponse.errorCode())); | ||
| memberError); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: We could revert this change as it does not bring much and re-align like it was before.
| } | ||
|
|
||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Could we add an empty line back?
| final String unexpectedErrorMsg = | ||
| String.format("`LeaveGroup` request for group id %s failed due to unexpected error %s", groupId.idValue, error); | ||
| log.error(unexpectedErrorMsg); | ||
| failed.put(groupId, error.exception(unexpectedErrorMsg)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: As said in the other PR, this is a good idea but I would only do it if we do it for all exceptions.
| MemberResponse memberResponse = new MemberResponse() | ||
| .setGroupInstanceId(groupId) | ||
| .setErrorCode(Errors.COORDINATOR_LOAD_IN_PROGRESS.code()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that we could remove this test as it is not possible to have COORDINATOR_LOAD_IN_PROGRESS as an error for a member, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right! Removed. Thanks.
dajac
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks.
|
I've re-triggered Jenkins. |
|
Thank you. it have been running for whole day. :) |
|
Failures are not related: |
…RDINATOR_NOT_AVAILABLE error (#11035) This patch improve the error handling in `RemoveMembersFromConsumerGroupHandler` and ensures that `COORDINATOR_NOT_AVAILABLE` is unmapped in order to look up the coordinator again. Reviewers: David Jacot <djacot@confluent.io>
|
Merged to trunk and 3.0. cc @kkonstantine |
…RDINATOR_NOT_AVAILABLE error (apache#11035) This patch improve the error handling in `RemoveMembersFromConsumerGroupHandler` and ensures that `COORDINATOR_NOT_AVAILABLE` is unmapped in order to look up the coordinator again. Reviewers: David Jacot <djacot@confluent.io>
refactor RemoveMembersFromConsumerGroupHandler and tests. Also, put COORDINATOR_NOT_AVAILABLE as unmap retry.
This is the old handle response logic. FYR:
Committer Checklist (excluded from commit message)