...

This means we are creating 4 new instance ids compared with previous round, so broker could no longer leverage the static information it stored. Basically, the scenario invalidates static membership effectiveness.

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.

...

Each stream instance will use local counter to create stream thread name. So the above example will be always generating instance ids as:  A-1, A-2, B-1, B-2. By persisting instance ids generation, the static membership will still behave as expected when we configure > 1 stream instances in one JVM.

Public Interfaces

This change is internal, however it will affect KStream external information exposure. See next section.

Compatibility, Deprecation, and Migration Plan

• There is no anticipated broken  negative impact. The thread-id is used to construct many stream component identifiers such as producer/consumer/stream thread names. If user exposes these information in their production environment, upgraded service may see different composed ids from previous round. Note that this only applies to multi-instance one JVM scenario and only one time, thus not going to globally affect things too much in general.

Rejected Alternatives

N/A