We learned the hard way that Kafka Streams will reuse Processor objects by calling init() on them after they've been close()d. This caused a bug in our application as we assumed we didn't have to reset all of our Processor's state to a proper starting state on init().
As far as I can tell, this is completely undocumented. The fact that we provide Processors to Kafka Streams via a ProcessorSupplier factory rather than just by passing in a Processor object made it seem likely that in fact Streams was creating Processors from scratch each time it needed a new one.
The developer guide (https://docs.confluent.io/current/streams/developer-guide/processor-api.html) doesn't even allude to the existence of the close() method, let alone the idea that init() may be called after close().
The Javadocs for Processor.init says: "The framework ensures this is called once per processor when the topology that contains it is initialized." I personally interpreted that as meaning that it only is ever called once! I can see that you could interpret it otherwise, but it's definitely unclear.
I can send a PR but first want to confirm that this is a doc problem and not a bug!