Skip to content
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

bugfix kgo: do not default to eager if there is any eager balancer #384

Merged
merged 1 commit into from
Mar 13, 2023
Merged

Conversation

twmb
Copy link
Owner

@twmb twmb commented Mar 11, 2023

The previous cooperative check was wrong: if you used multiple group balancers, if any were eager, the client would think you were eager consuming.

However this bug did not affect all areas of group balancing, which actually made the bug worse. If everything in the code went eager, then the bug would just be "you saw more stop the world than was intended". Instead, if the chosen balancer was cooperative, then cooperative balancing would occur for eager consumers. On rebalance, partitions would be lost, and then a cooperative rebalance would not occur, meaning the partitions would be stuck until another rebalance.

We fix this by saving if we are cooperative based on the rebalancer that is actually chosen.

This is an upgrade path that should happen once -- once to cooperative -- but we can downgrade if the user adds a random eager balancer. This is not supported per KIP-429 so we just warn log and continue as best we can (likely with duplicate consumption).

Closes #366.

The previous cooperative check was wrong: if you used multiple group
balancers, if any were eager, the client would think you were eager
consuming.

However this bug did not affect all areas of group balancing, which
actually made the bug worse. If everything in the code went eager, then
the bug would just be "you saw more stop the world than was intended".
Instead, if the chosen balancer was cooperative, then cooperative
balancing would occur for eager consumers. On rebalance, partitions
would be lost, and then a cooperative rebalance would not occur, meaning
the partitions would be stuck until another rebalance.

We fix this by saving if we are cooperative based on the rebalancer that
is actually chosen.

This is an upgrade path that should happen once -- once to cooperative
-- but we can downgrade if the user adds a random eager balancer. This
is not supported per KIP-429 so we just warn log and continue as best we
can (likely with duplicate consumption).

Closes #366.
@twmb twmb merged commit 14b89d6 into master Mar 13, 2023
@twmb twmb deleted the 366 branch March 13, 2023 18:59
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.

sometimes consumer have no partition assigned to it after rebalance
1 participant