What I meant is that, for some changes (e.g. say we change the auto-repartition behavior that caused using different name conventions, or some changes that involve changing the underlying state store names, etc) the existing internal state including the stores and topics will probably not valid. Some users consider this also as a "backward incompatible change" since they cannot just swipe in the new jar and restart.
Guozhang On Wed, Nov 23, 2016 at 3:20 PM, Matthias J. Sax <matth...@confluent.io> wrote: > Thanks for the feedback. I updated the KIP for (1) and (2). > > However not for (3): Why should it be required to reset an application? > If user processed "good" data with valid timestamps, behavior does not > change. If user tried to process "bad" data with invalid timestamps, the > application does fail currently anyway, so there is nothing to reset. > > > -Matthias > > On 11/22/16 9:53 AM, Guozhang Wang wrote: > > Regarding the "compatibility" section, I would suggest being a bit more > > specific about why it is a breaking change. For Streams, it could mean > > different things: > > > > 1. User need code change when switching library dependency on the new > > version, otherwise it won't compile(I think this is the case for this > KIP). > > 2. User need code change when switching library dependency on the new > > version, otherwise runtime exception will be thrown. > > 3. Existing application state as well as internal topics need to be > swiped > > and the program need to restart from zero. > > > > > > Guozhang > > > > On Fri, Nov 18, 2016 at 12:27 PM, Matthias J. Sax <matth...@confluent.io > > > > wrote: > > > >> Hi all, > >> > >> I want to start a discussion about KIP-93: > >> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP- > >> 93%3A+Improve+invalid+timestamp+handling+in+Kafka+Streams > >> > >> Looking forward to your feedback. > >> > >> > >> -Matthias > >> > >> > > > > > > -- -- Guozhang
