You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Guozhang Wang (JIRA)" <ji...@apache.org> on 2018/05/16 20:11:00 UTC

[jira] [Resolved] (KAFKA-6905) Document that Processor objects can be reused

     [ https://issues.apache.org/jira/browse/KAFKA-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guozhang Wang resolved KAFKA-6905.
----------------------------------
       Resolution: Fixed
    Fix Version/s: 2.0.0

> Document that Processor objects can be reused
> ---------------------------------------------
>
>                 Key: KAFKA-6905
>                 URL: https://issues.apache.org/jira/browse/KAFKA-6905
>             Project: Kafka
>          Issue Type: Improvement
>          Components: documentation, streams
>            Reporter: David Glasser
>            Priority: Major
>             Fix For: 2.0.0
>
>
> 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!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)