Versions Compared

Key

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

...

Client side changes

The new "member.name" config `member.name` config will be added to the join group request.

...

Code Block
titleAdminClient.java
public static MembershipChangeResult forceStaticRebalance(String groupId)


Proposed Changes

In short, the proposed feature is enabled if 

  1. JoinGroupRequest V4 is supported on both client and broker
  2. `member.name` is configured with non-empty string.

Client behavior changes

On client side, we add a new config called MEMBER_NAME in ConsumerConfig. On consumer service init, if the MEMBER_NAME config is set, we will put it in the initial join group request to identify itself as a static member (static membership); otherwise, we will still send UNKNOWN_MEMBER_ID to ask broker for allocating a new random ID (dynamic membership). Note that it is user's responsibility to assign unique member id for each consumers. This could be in service discovery hostname, unique IP address, etc. We also have logic handling duplicate member.name in duplicate `member.name` in case client configured it wrong.

For the effectiveness of the KIP, consumer with memberwith `member.name set name` set will not send leave group request when they go offline, which means we shall only rely on session.timeout to trigger group rebalance. It is because the proposed rebalance protocol will trigger rebalance with this intermittent in-and-out which is not ideal. In static membership we leverage the consumer group health management to client application such as K8. Therefore, it is also advised to make the session timeout large enough so that broker side will not trigger rebalance too frequently due to member come and go.

...

  • Member.id must be set if the member`member.name is name` is already within the map. Otherwise reply MISSING_MEMBER_ID 
  • Member.id must be left empty if the member`member.namename` is new. Otherwise reply DUPLICATE_STATIC_MEMBER

...

In this pull request, we did an experimental approach to materialize member id(the identity given by broker, equivalent to the member`member.name name` 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:

...