[jira] [Commented] (KAFKA-3455) Connect custom processors with the streams DSL

["Bobby Calderwood (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048626#comment-16048626 ] 

Bobby Calderwood commented on KAFKA-3455:
-----------------------------------------

Hi Michal Borowiecki,

Sorry for the late reply.  I am trying to implement both {{Transformer}} and {{Processor}} on the same class.  For some interesting use-cases in a Clojure compatibility library for Kafka Streams that I'm writing, I'd like to hook a single piece of logic into both the high-level (via {{Transformer}}) and low-level (via {{Processor}}) APIs.  However, when implementing both interfaces, I encounter the following error due to differing signatures of the respective {{punctuate(long)}} methods:

{code:none}
<redacted>/TransducerProcessor.java
    Error:Error:line (44)java: method punctuate(long) is already defined in class kafka_streams_clojure.TransducerProcessor
    Error:Error:line (10)java: kafka_streams_clojure.TransducerProcessor is not abstract and does not override abstract method punctuate(long) in org.apache.kafka.streams.kstream.Transformer
    Error:Error:line (40)java: punctuate(long) in kafka_streams_clojure.TransducerProcessor cannot implement punctuate(long) in org.apache.kafka.streams.kstream.Transformer
  return type void is not compatible with java.lang.Object
{code}

I believe you're right about AutoCloseable, it's been a while since I've been in Java-land :-)

Yes, I believe that once the incompatible punctuate methods are deprecated and then removed, my issue would be resolved.

> Connect custom processors with the streams DSL
> ----------------------------------------------
>
>                 Key: KAFKA-3455
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3455
>             Project: Kafka
>          Issue Type: Sub-task
>          Components: streams
>    Affects Versions: 0.10.0.1
>            Reporter: Jonathan Bender
>              Labels: user-experience
>
> From the kafka users email thread, we discussed the idea of connecting custom processors with topologies defined from the Streams DSL (and being able to sink data from the processor).  Possibly this could involve exposing the underlying processor's name in the streams DSL so it can be connected with the standard processor API.
> {quote}
> Thanks for the feedback. This is definitely something we wanted to support
> in the Streams DSL.
> One tricky thing, though, is that some operations do not translate to a
> single processor, but a sub-graph of processors (think of a stream-stream
> join, which is translated to actually 5 processors for windowing / state
> queries / merging, each with a different internal name). So how to define
> the API to return the processor name needs some more thinking.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)