Skip to content

KAFKA-12648: fix bug where thread is re-added to TopologyMetadata whe…#674

Merged
A. Sophie Blee-Goldman (ableegoldman) merged 1 commit into
confluentinc:masterfrom
wcarlson5:cherry_pick_fix
Mar 9, 2022
Merged

KAFKA-12648: fix bug where thread is re-added to TopologyMetadata whe…#674
A. Sophie Blee-Goldman (ableegoldman) merged 1 commit into
confluentinc:masterfrom
wcarlson5:cherry_pick_fix

Conversation

@wcarlson5

Copy link
Copy Markdown

Cherry pick one commit over. It is the next one on master so it won't mess up the order when the sync fainlly works

We used to call TopologyMetadata#maybeNotifyTopologyVersionWaitersAndUpdateThreadsTopologyVersion when a thread was being unregistered/shutting down, to check if any of the futures listening for topology updates had been waiting on this thread and could be completed. Prior to invoking this we make sure to remove the current thread from the TopologyMetadata's threadVersions map, but this thread is actually then re-added in the #maybeNotifyTopologyVersionWaitersAndUpdateThreadsTopologyVersion call.

To fix this, we should break up this method into separate calls for each of its two distinct functions, updating the version and checking for topology update completion. When unregistering a thread, we should only invoke the latter method

Reviewers: Guozhang Wang guozhang@confluent.io, Walker Carlson wcarlson@confluent.io

More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.

Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.

Committer Checklist (excluded from commit message)

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

…n shutting down (apache#11857)

We used to call TopologyMetadata#maybeNotifyTopologyVersionWaitersAndUpdateThreadsTopologyVersion when a thread was being unregistered/shutting down, to check if any of the futures listening for topology updates had been waiting on this thread and could be completed. Prior to invoking this we make sure to remove the current thread from the TopologyMetadata's threadVersions map, but this thread is actually then re-added in the #maybeNotifyTopologyVersionWaitersAndUpdateThreadsTopologyVersion call.

To fix this, we should break up this method into separate calls for each of its two distinct functions, updating the version and checking for topology update completion. When unregistering a thread, we should only invoke the latter method

Reviewers: Guozhang Wang <guozhang@confluent.io>, Walker Carlson <wcarlson@confluent.io>

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

LGTM, going to merge this but Walker Carlson (@wcarlson5) can you point out what the merge conflicts were? You mentioned it wasn't a smooth cherrypick, that seems quite odd if this is indeed the exact next commit in the history 🤔

@ableegoldman

Copy link
Copy Markdown

Test failure is unrelated: kafka.api.ConsumerBounceTest.testRollingBrokerRestartsWithSmallerMaxGroupSizeConfigDisruptsBigGroup()

@ableegoldman
A. Sophie Blee-Goldman (ableegoldman) merged commit 1bc2a33 into confluentinc:master Mar 9, 2022
@wcarlson5

Copy link
Copy Markdown
Author

There was no conflicts I just didn't have permissions

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.

2 participants