+1 (binding) Guozhang
On 2019/04/26 07:42:12, "Matthias J. Sax" <matth...@confluent.io> wrote: > Thanks for the KIP! > > I agree that the change makes sense, and not only for the static group > membership case. > > For example, if a user `closes()` a `KafkaStreams` client and creates a > new one (for example to recover failed threads), while the JVM is still > running, it is more intuitive that the thread names are number from 1 to > X again, and not from X+1 to 2*x on restart. > > Also, the original idea about making thread names unique across > application is non-intuitive itself. It might make sense if there are > two instances of the same application within one JVM -- however, this > seems to be a rather rare case. Also, the only pattern for this use case > seems to by dynamic scaling, and I believe we should actually void this > pattern by adding a `stopThread()` and `addThread()` method to > `KafkaStreams` directly. > > > -Matthias > > > On 4/25/19 11:13 PM, Boyang Chen wrote: > > Hey friends, > > > > I would like to start discussion for a very small KIP: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-462%3A+Use+local+thread+id+for+KStreams > > > > it is trying to avoid sharing thread-id increment between multiple stream > > instances configured in one JVM. This is an important fix for static > > membership<https://cwiki.apache.org/confluence/display/KAFKA/KIP-345%3A+Introduce+static+membership+protocol+to+reduce+consumer+rebalances> > > to be effective for KStreams in edge case like changing > > `group.instance.id` throughout restarts due to thread-id interleaving. > > > > I will open the vote thread in the main while, since this is a very small > > fix. Feel free to continue the discussion on this thread, thank you! > > > > Boyang > > > >
