Versions Compared

Key

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

...

group.instance.id

The unique identifier of the consumer instance provided by end user.

Default value: empty string.

Stream configs

...

stream.instance.id

...

The unique identifier of the stream instance provided by end user.

Default value: empty string.

Client side changes

The new `group.instance.id` config will be added to the join group request, and a list of `group.instance.id` will be added to the LeaveGroupRequest.

Code Block
JoinGroupRequest => GroupId SessionTimeout RebalanceTimeout MemberId GroupMemberName ProtocolType GroupProtocols
  GroupId             => String
  SessionTimeout      => int32
  RebalanceTimeout	  => int32
  MemberId            => String
  GroupMemberName     => String // new
  ProtocolType        => String
  GroupProtocols      => [Protocol MemberMetadata]
  Protocol            => String
  MemberMetadata      => bytes

In the meantime, we bump the join group request/response version to v4.

...

For example if user specifies the client id, the stream consumer client id will be like: User client id + "-StreamThread-" + thread id + "-consumer"If user client id is not set, then we will use process id.

We could use a similar setting for defining `group.instance.id` on Stream. `stream.instance.id` (defined above) would be used as prefix, and for each thread consumer the formula will look like:
`group.instance.id` = `stream.instance.id` + "-" + thread id + "-consumer"

If the `stream.instance.id` is not set, we will not define `group.instance.id`. So the `stream.instance.id` is also used as the switch for using static membership on StreamOur plan is to reuse the above consumer client id to define `group.instance.id`, so effectively the KStream instance will be able to use static membership if end user defines unique `client.id` for stream instances.

Server behavior changes

On server side, broker will keep handling join group request <= v3 as before. The `member.id` generation and assignment is still coordinated by broker, and broker will maintain an in-memory mapping of {group.instance.id → member.id} to track member uniqueness. When receiving an known member's (A.K.A `group.instance.id` known) rejoin request, broker will return the cached assignment back to the member, without doing any rebalance.

...