...

Also notice 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 to avoid conflict thread names. After Although, semantically we would not forbid users to set the same client.ids for throttling purposes for example. After this KIP, we are effectively removing this guard, so it is user's responsibility to configure unique client.ids if they don't want to see this single JVM conflict issue. We will do extra documentation on `client.id` config to remind user as necessarysince 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.

Public Interfaces

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

...