[
https://issues.apache.org/jira/browse/KAFKA-6738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16740572#comment-16740572
]
Jordan Moore edited comment on KAFKA-6738 at 1/11/19 5:38 PM:
--------------------------------------------------------------
Hi [~wicknicks] / [~rhauch],
-I can't seem to find documentation on Apache or Confluent site how these
features can be used, or what classnames are available for the configurations-.
*Edit*: Nevermind found it. Was looking at the wrong section -
https://kafka.apache.org/documentation/#sinkconnectconfigs
was (Author: cricket007):
Hi [~wicknicks] / [~rhauch],
I can't seem to find documentation on Apache or Confluent site how these
features can be used, or what classnames are available for the configurations.
> Kafka Connect handling of bad data
> ----------------------------------
>
> Key: KAFKA-6738
> URL: https://issues.apache.org/jira/browse/KAFKA-6738
> Project: Kafka
> Issue Type: Improvement
> Components: KafkaConnect
> Affects Versions: 1.1.0
> Reporter: Randall Hauch
> Assignee: Arjun Satish
> Priority: Critical
> Fix For: 2.0.0
>
>
> Kafka Connect connectors and tasks fail when they run into an unexpected
> situation or error, but the framework should provide more general "bad data
> handling" options, including (perhaps among others):
> # fail fast, which is what we do today (assuming connector actually fails and
> doesn't eat errors)
> # retry (possibly with configs to limit)
> # drop data and move on
> # dead letter queue
> This needs to be addressed in a way that handles errors from:
> # The connector itself (e.g. connectivity issues to the other system)
> # Converters/serializers (bad data, unexpected format, etc)
> # SMTs
> # Ideally the framework as well, though we obviously want to fix known bugs
> anyway
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
