kafka-jira mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paolo Patierno (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-5684) KStreamPrintProcessor as customized KStreamPeekProcessor
Date Wed, 02 Aug 2017 13:04:00 GMT

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

Paolo Patierno commented on KAFKA-5684:
---------------------------------------

Maybe I made a mistake here because the default serdes are available only from the {{ProcessorContext}}
(using the Streams configuration). The same is for the topic which is needed for deserialization.
So in any case the checks for a) and b) are something that should happen inside the processor
node.

> KStreamPrintProcessor as customized KStreamPeekProcessor
> --------------------------------------------------------
>
>                 Key: KAFKA-5684
>                 URL: https://issues.apache.org/jira/browse/KAFKA-5684
>             Project: Kafka
>          Issue Type: Improvement
>          Components: streams
>            Reporter: Paolo Patierno
>            Assignee: Paolo Patierno
>            Priority: Minor
>
> Hi,
> the {{KStreamPrintProcessor}} is implemented from scratch (from the {{AbstractProcessor}})
and the same for the related supplier.
> It looks to me that it's just a special {{KStreamPeekProcessor}} with forwardDownStream
to false and that allows the possibility to specify Serdes instances used if key/values are
bytes.
> At same time used by a {{print()}} method it provides a fast way to print data flowing
through the pipeline (while using just {{peek()}} you need to write the code).
> I think that it could be useful to refactoring the {{KStreamPrintProcessor}} as derived
from the {{KStreamPeekProcessor}} customizing its behavior.
> Thanks,
> Paolo.



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

Mime
View raw message