Skip to content

HOTFIX: cherry-pick KAFKA-13563 compatiblity fix into 3.1#723

Merged
Philip Nee (philipnee) merged 1 commit into
3.1from
cherry-pick-kafka-13563-3.1
Jun 8, 2022
Merged

HOTFIX: cherry-pick KAFKA-13563 compatiblity fix into 3.1#723
Philip Nee (philipnee) merged 1 commit into
3.1from
cherry-pick-kafka-13563-3.1

Conversation

@philipnee

@philipnee Philip Nee (philipnee) commented Jun 7, 2022

Copy link
Copy Markdown

…2244) (apache#12259)

This is a cherrypick commit of 3.1. Another way of fixing KAFKA-13563 other than apache#11631.

Instead of letting the consumer to always try to discover coordinator in pool with either mode (subscribe / assign), we defer the clearance of discover future upon committing async only. More specifically, under manual assign mode, there are only three places where we need the coordinator:

commitAsync (both by the consumer itself or triggered by caller), this is where we want to fix.
commitSync, which we already try to re-discovery coordinator.
committed (both by the consumer itself based on reset policy, or triggered by caller), which we already try to re-discovery coordinator.
The benefits are that for manual assign mode that does not try to trigger any of the above three, then we never would be discovering coordinator. The original fix in apache#11631 would let the consumer to discover coordinator even if none of the above operations are required.

Reviewers: Luke Chen showuon@gmail.com, David Jacot djacot@confluent.io

Committer Checklist (excluded from commit message)

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

…ache#12244) (apache#12259)

This is a cherrypick commit of 3.1. Another way of fixing KAFKA-13563 other than apache#11631.

Instead of letting the consumer to always try to discover coordinator in pool with either mode (subscribe / assign), we defer the clearance of discover future upon committing async only. More specifically, under manual assign mode, there are only three places where we need the coordinator:

commitAsync (both by the consumer itself or triggered by caller), this is where we want to fix.
commitSync, which we already try to re-discovery coordinator.
committed (both by the consumer itself based on reset policy, or triggered by caller), which we already try to re-discovery coordinator.
The benefits are that for manual assign mode that does not try to trigger any of the above three, then we never would be discovering coordinator. The original fix in apache#11631 would let the consumer to discover coordinator even if none of the above operations are required.

Reviewers: Luke Chen <showuon@gmail.com>, David Jacot <djacot@confluent.io>

@ijuma Ismael Juma (ijuma) 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.

@philipnee Philip Nee (philipnee) merged commit ef2b913 into 3.1 Jun 8, 2022
@philipnee Philip Nee (philipnee) deleted the cherry-pick-kafka-13563-3.1 branch June 8, 2022 13:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants