[ 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)