You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Marcel childNo͡.de Trautwein (JIRA)" <ji...@apache.org> on 2018/02/22 09:04:00 UTC

[jira] [Commented] (KAFKA-5157) Options for handling corrupt data during deserialization

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

Marcel "childNo͡.de" Trautwein commented on KAFKA-5157:
-------------------------------------------------------

Just a question ... What I "dislike" here from a native point of view, is that if you want to configure your implementing {{DeserializationExceptionHandler}} you have that well defined {{Configurable}} interface, but what is injected is the {{StreamsConfig}} so you have to put configurations into the streamsConfig map to access them later in the implementation ... is this really the desired / designed procedure and / or best practice?

> Options for handling corrupt data during deserialization
> --------------------------------------------------------
>
>                 Key: KAFKA-5157
>                 URL: https://issues.apache.org/jira/browse/KAFKA-5157
>             Project: Kafka
>          Issue Type: Sub-task
>          Components: streams
>            Reporter: Eno Thereska
>            Assignee: Eno Thereska
>            Priority: Major
>              Labels: user-experience
>             Fix For: 1.0.0
>
>
> When there is a bad formatted data in the source topics, deserialization will throw a runtime exception all the way to the users. And since deserialization happens before it was ever processed at the beginning of the topology, today there is no ways to handle such errors on the user-app level.
> We should consider allowing users to handle such "poison pills" in a customizable way.



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