-
Notifications
You must be signed in to change notification settings - Fork 579
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
kafka: expire pending group members #3761
kafka: expire pending group members #3761
Conversation
if (g._partition) { | ||
return fmt::format("{}", g._partition->ntp()); | ||
} else { | ||
return std::string("<none>"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
constexpr string_view? for these static strings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wish but I dunno how the types would be compatible
good find! |
sorry! i meant to hit 'comment' |
99a59dd
to
912f89d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks great, the only thing is that some of the tests are failing.
Prior to this change a pending member that never rejoins might leave a pending member indefinitely. Now we kick em out. When pending members stick around it may cause issues when trying to determine of all members have joined. The function all members joined will return false if any pending member exists, which would occur if a pending member were left lingering in the group and this in turn may prevent the group from properly transitioning through the state machine. For example, the inline join completion that occurs in handle_join_group as well as in the complete_join callback all have scenarios gated on this condition which would prevent the group from moving into the sync phase. Signed-off-by: Noah Watkins <noah@redpanda.com>
On join we dump out a lot of metadata about the group and members at trace level. This is to aid in debugging stuck groups if they occur again. Signed-off-by: Noah Watkins <noah@redpanda.com>
912f89d
to
a41cb00
Compare
@mmaslankaprv force pushed ⬆️ to fix use-after-free bug that was causing the CI failure. |
ping @mmaslankaprv |
Cover letter
Prior to this change a pending member that never rejoins might leave a
pending member indefinitely. Now we kick em out.
When pending members stick around it may cause issues when trying to
determine of all members have joined. The function all members joined
will return false if any pending member exists, which would occur if a
pending member were left lingering in the group and this in turn may
prevent the group from properly transitioning through the state machine.
For example, the inline join completion that occurs in handle_join_group
as well as in the complete_join callback all have scenarios gated on
this condition which would prevent the group from moving into the sync
phase.
Release notes