Hi all,
It definitely would be nice to reuse whatever state is still valid after a
topology update, and KIP-307 is indeed likely what we have to do to solve
that problem. The discuss thread for the KIP hasn't gotten a lot of traffic
recently, so it might be nice if you reply to it with your though
Hi Cédric
1. You should be able to rebuild your internal state after doing a full
reset (Deleting all internal topics). The application will just need to
consume data from the beginning of the input streams and rebuild the state
accordingly. If you don't want to lose the state, or if it is too exp
Thanks John and Adam for your answer,
After investigation, I am exactly in the case you describe John.
After a modification in my toplogy, a processor KEY-SELECT get the same
number of an old processor KEY-SELECT with the associated repartition topic.
We use the app reset tool to clean all interna
Hi Cédric,
The suffix is generated when we build the topology in such a way to
guarantee each node/interna-topic/state-store gets a unique name.
Generally speaking, it is unsafe to modify the topology and restart it. We
recommend using the app reset tool whenever you update your topology.
That s
Hi Cédric
I do not know how the topology names are chosen, but provided that you
didn't change any of the topology then new topics will not be created or
require alteration.
If you modify the topology then the naming can indeed change, but it would
then create a new internal topic and there would
Within the Kafka Stream topology, internal topic are created.
For this internal topics, schema avro for key and value are registered into
schema registry.
For the topic internal-MYAPPS-KSTREAM-KEY-SELECT-99-repartition, I
have 2 subjects into schema registry :
- internal-MYAPPS-KSTREAM-KEY
