KAFKA-14500; [5/N] Implement JoinGroup protocol in new GroupCoordinator#13870
Conversation
dajac
left a comment
There was a problem hiding this comment.
@jeffkbkim Thanks for the PR. I have started to read it. I left a few preliminary comments.
dajac
left a comment
There was a problem hiding this comment.
I am still processing the PR. I left a few more comments in the meantime.
dajac
left a comment
There was a problem hiding this comment.
I am still processing the PR. I left a few more comments.
dajac
left a comment
There was a problem hiding this comment.
@jeffkbkim Thanks for the hard work on this one! I have compared the new implementation with the old implementation line by line. It looks pretty good. I left some comments, mainly nits. I will do a second pass on it on Monday and start looking into the tests as well.
There was a problem hiding this comment.
in GroupMetadataManager#expirePendingSync() we remove members from the set while iterating
There was a problem hiding this comment.
Would it make sense to make the copy on the other side? It is a bit weird to anticipate this here because we don't do this for other accessors. I am usually tempted to return unmodifiable collections in the case to prevent this kind of issue.
There was a problem hiding this comment.
thought i addressed this. addressed it now
dajac
left a comment
There was a problem hiding this comment.
@jeffkbkim Thanks for the hard work on this one! I have compared the new implementation with the old implementation line by line. It looks pretty good. I left some comments, mainly nits. I will do a second pass on it on Monday and start looking into the tests as well.
|
There are issues with the build as well. Could you look into this? |
|
@dajac @CalvinConfluent thanks for the review, i have addressed your comments. |
dajac
left a comment
There was a problem hiding this comment.
I just made a pass on the main files and left more comments/suggestions.
There was a problem hiding this comment.
I wonder if we should remove this because it will log all errors now.
There was a problem hiding this comment.
this would log all errors while appending/committing and if generateRecordsAndResponse throws an unexpected exception. shouldn't we log them?
it doesn't seem like we do for consumerGroupHeartbeat() -- maybe just filter out the coordinator not available / not coordinator error codes?
There was a problem hiding this comment.
Yeah, I think that it depends on what we mean by unexpected. I would remove it for now given that we also log something when the append future fails. We can always bring it back later if needed.
There was a problem hiding this comment.
i was thinking about the illegal state exceptions. wouldn't we hide the issue then? maybe we can log only for non api exceptions. wdyt?
There was a problem hiding this comment.
changed to logging only when the response future is not complete
dajac
left a comment
There was a problem hiding this comment.
I am half way through the tests. Continuing...
dajac
left a comment
There was a problem hiding this comment.
I left a few more comments related to the remaining tests.
|
@dajac thanks for the review. I have addressed your comments. |
|
@jeffkbkim Now that #13963 is merged, could you update your PR? |
|
@dajac I have updated with latest and unified the MockCoordinatorTimer. |
dajac
left a comment
There was a problem hiding this comment.
@jeffkbkim Thanks for the update. I just made a full pass on it and I left some small comments (mainly nits). We should be good to merge it afterwards.
There was a problem hiding this comment.
Yeah, I think that it depends on what we mean by unexpected. I would remove it for now given that we also log something when the append future fails. We can always bring it back later if needed.
checkstyle remove unused address comments address comments; add replay generate record when creating new group use scheduleWriteOperation generate records for new group only when no records were created address comments address comments, fix tests build fix address comments build fix small fix address comments address comments validate records on caller's side separate test for new group records fix build
|
the test failures are unrelated |
…or (apache#13870) This patch implements the existing JoinGroup protocol within the new group coordinator. Some notable differences: * Methods return a CoordinatorResult to the runtime framework, which includes records to append to the log as well as a future to complete after the append succeeds/fails. * The coordinator runtime ensures that only a single thread will be processing a group at any given time, therefore there is no more locking on groups. * Instead of using on purgatories, we rely on the Timer interface to schedule/cancel delayed operations. Reviewers: David Jacot <djacot@confluent.io>
…or (apache#13870) This patch implements the existing JoinGroup protocol within the new group coordinator. Some notable differences: * Methods return a CoordinatorResult to the runtime framework, which includes records to append to the log as well as a future to complete after the append succeeds/fails. * The coordinator runtime ensures that only a single thread will be processing a group at any given time, therefore there is no more locking on groups. * Instead of using on purgatories, we rely on the Timer interface to schedule/cancel delayed operations. Reviewers: David Jacot <djacot@confluent.io>
…or (apache#13870) This patch implements the existing JoinGroup protocol within the new group coordinator. Some notable differences: * Methods return a CoordinatorResult to the runtime framework, which includes records to append to the log as well as a future to complete after the append succeeds/fails. * The coordinator runtime ensures that only a single thread will be processing a group at any given time, therefore there is no more locking on groups. * Instead of using on purgatories, we rely on the Timer interface to schedule/cancel delayed operations. Reviewers: David Jacot <djacot@confluent.io>
Built on top of #13812, this PR aims to implement the existing JoinGroup protocol within the new group coordinator.
For reviewing, one can start with
GroupMetadataManager#genericGroupJoin().Some notable differences:
Committer Checklist (excluded from commit message)