Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

 The static membership metadata stored on broker will eventually be wiped out when the corresponding `member.id` reaches session timeout. 

On switching from static member to dynamic member

A corner case is that although we don't allow static member to send LeaveGroupRequest, it is possible that broker receives a leaveGroupRequest whose `member.id` field points to a static member. This could be due to a sequence of operations like below:

  1. A static member successfully joins the group
  2. Client did a restart and remove `group.instance.id` from the member consumer (switching back to dynamic member)
  3. Client won't send the LeaveGroupRequest, and the restart time was faster than session timeout.
  4. The dynamic member rejoins the group without `group.instance.id`. It will be accepted since it is a known member.
  5. Client did another restart. As a dynamic member, it sends LeaveGroupRequest to the broker.
  6. Broker detects a LeaveGroupRequest with `member.id` attributing to a static member.

The straightforward solution will be adopted here, which is we will remove the member metadata all together including the static member info. This approach ensures that downgrade process has no negative impact on the normal consumer operation, and avoids complicating the server side logic.

Non-goal

We do have some offline discussions on handling leader rejoin case, where due to the possible topic assignment change (adding or removing topics), we still need to start a rebalance. However since the broker could also do the subscription monitoring work, we don't actually need to trigger rebalance on leader side blindly based on its rejoin request. This is a separate topic from 345 and we could address it in another KIP. are tracking the discussion in this

Jira
serverASF JIRA
serverId5aa69414-a9e9-3523-82ec-879b028fb15b
keyKAFKA-7728
.

Rejected Alternatives

In this pull request, we did an experimental approach to materialize member id(the identity given by broker, equivalent to the `group.instance.id` in proposal) on the instance local disk. This approach could reduce the rebalances as expected, which is the experimental foundation of KIP-345. However, KIP-345 has a few advantages over it:

...