...

In the current consumer protocol, the field `member.id` is assigned by broker to track group member status. A new consumer joins the group with `member.id` field set as UNKNOWN_MEMBER_ID (empty string), since it needs to receive the identity assignment from broker first. For request with unknown member id, Broker will blindly accept the new join group request, store the member metadata and return a UUID to consumer. The edge case is that if initial join group request fails, or the consumer keeps restarting, there will be many leftover MemberMetadata within group metadata cache which will eventually burst broker memory. The detection and fencing of invalid join group request is crucial for broker stability.

Public Interfaces

Briefly list any new interfaces that will be introduced as part of this proposal or any existing interfaces that will be removed or changed. The purpose of this section is to concisely call out the public contract that will come along with this feature.

A public interface is any change to the following:

...

Binary log format

...

The network protocol and api behavior

...

Any class in the public packages under clientsConfiguration, especially client configuration

• org/apache/kafka/common/serialization

• org/apache/kafka/common

• org/apache/kafka/common/errors

• org/apache/kafka/clients/producer

• org/apache/kafka/clients/consumer (eventually, once stable)

...

Monitoring

...

Command line tools and arguments

This KIP is a parallel work with KIP-389 which tries to enforce hard cap on the group metadata size, and an important compliment for KIP-345 which introduces static membership

Public Interfaces

We will introduce a new join group response type.

...

Proposed Changes

Describe the new thing you want to do in appropriate detail. This may be fairly extensive and have large subsections of its own. Or it may be a few sentences. Use judgement based on the scope of the change.

...