Status

Current state: Under DiscussionAccepted (2.3.0)

Discussion thread: TBD

JIRA:

...

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.

Also notice the The original goal for using static integer to increment thread.id is to workaround the case where two stream instances configure same client.id in one JVM and trying , in order to avoid conflict thread names. AlthoughAnd note that, semantically we would not forbid users to set the same client.ids for throttling purposes for example. After this KIP, since this guard of fencing same client.ids of instances is removed, we will augment the client.id config description by stating what users should expect client.id to be propagated to internal embedded clients, and therefore what's the expected outcome if they choose to set same client.ids for different Streams client.

...

• There is no anticipated 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. The only pattern for this use case seems to be dynamic scaling, and we should actually void this pattern by adding a `stopThread()` and `addThread()` method to `KafkaStreams` directly.
• No deprecation/migration needed for this change.

Rejected Alternatives

N/A