Skip to content

KAFKA-14500; [5/N] Implement JoinGroup protocol in new GroupCoordinator#13870

Merged
dajac merged 14 commits into
apache:trunkfrom
jeffkbkim:KAFKA-14500-5
Jul 19, 2023
Merged

KAFKA-14500; [5/N] Implement JoinGroup protocol in new GroupCoordinator#13870
dajac merged 14 commits into
apache:trunkfrom
jeffkbkim:KAFKA-14500-5

Conversation

@jeffkbkim

@jeffkbkim jeffkbkim commented Jun 16, 2023

Copy link
Copy Markdown
Contributor

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:

  • 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.

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

@jeffkbkim jeffkbkim changed the title KAFKA-14500; [5/N] KAFKA-14500; [5/N] Implement JoinGroup protocol in new GroupCoordinator Jun 16, 2023
@dajac dajac added the KIP-848 The Next Generation of the Consumer Rebalance Protocol label Jun 17, 2023
@dajac
dajac self-requested a review June 17, 2023 02:25

@dajac dajac left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jeffkbkim Thanks for the PR. I have started to read it. I left a few preliminary comments.

@dajac dajac left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am still processing the PR. I left a few more comments in the meantime.

@dajac dajac left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am still processing the PR. I left a few more comments.

@dajac dajac left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need a copy here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in GroupMetadataManager#expirePendingSync() we remove members from the set while iterating

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was not addressed.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thought i addressed this. addressed it now

@dajac dajac left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

@dajac

dajac commented Jul 7, 2023

Copy link
Copy Markdown
Member

There are issues with the build as well. Could you look into this?

@jeffkbkim

Copy link
Copy Markdown
Contributor Author

@dajac @CalvinConfluent

thanks for the review, i have addressed your comments.

@dajac dajac left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just made a pass on the main files and left more comments/suggestions.

Comment on lines 299 to 298

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should remove this because it will log all errors now.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was not addressed.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed to logging only when the response future is not complete

@dajac dajac left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am half way through the tests. Continuing...

@dajac dajac left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a few more comments related to the remaining tests.

@jeffkbkim

Copy link
Copy Markdown
Contributor Author

@dajac thanks for the review. I have addressed your comments.

@dajac

dajac commented Jul 12, 2023

Copy link
Copy Markdown
Member

@jeffkbkim Now that #13963 is merged, could you update your PR?

@jeffkbkim

Copy link
Copy Markdown
Contributor Author

@dajac I have updated with latest and unified the MockCoordinatorTimer.

@dajac dajac left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Comment on lines 299 to 298

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Comment thread core/src/main/scala/kafka/server/BrokerServer.scala Outdated
@jeffkbkim

Copy link
Copy Markdown
Contributor Author

the test failures are unrelated

@dajac dajac left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks @jeffkbkim!

@dajac
dajac merged commit a500c3e into apache:trunk Jul 19, 2023
jeqo pushed a commit to jeqo/kafka that referenced this pull request Jul 21, 2023
…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>
Cerchie pushed a commit to Cerchie/kafka that referenced this pull request Jul 25, 2023
…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>
jeqo pushed a commit to aiven/kafka that referenced this pull request Aug 15, 2023
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

KIP-848 The Next Generation of the Consumer Rebalance Protocol

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants