Table of Contents |
---|
This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.
Status
Current state: Adopted
Under Discussion thread: Here
Discussion Vote thread: here Here
JIRA: here
Jira | ||||||
---|---|---|---|---|---|---|
|
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Motivation
Currently, KIP-298 provides error handling in Kafka Connect that includes functionality such as retrying, logging, and sending errant records to a dead letter queue. However, the dead letter queue functionality from KIP-298 only supports error reporting within contexts of the transform operation, and key, value, and header converter operation.
...
After records are sent to the connector for processing, there is no support for dead letter queue/error reporting functionality.
As stated in rejected alternatives, ”Write records that fail in the put() step of a sink connector to the dead letter queue: since sink connectors can chose to batch records in a put() method, it is not clear what errors are caused by what records (they might be because of records that were immediately written to put(), or by some previous records that were processed later). Also, there might be connection issues that are not handled by the connector, and simply bubbled up as IOException (for example). Effectively, errors sent back to the framework from the put() method currently do not have sufficient context to determine the problematic records (if any). Addressing these issues would need a separate KIP. “
Beyond this, we currently have a proprietary connect-reporter
library with a Reporter
class. However, beyond the fact that we cannot use the proprietary library in the public sink connectors, using this library adds redundancy to configuration, as a user would have to configure this library in addition to the configuration properties already provided by the KIP-298 error handling functionality.
Thus, this proposal aims to extend KIP-298 and add error reporting functionality
...
even after records are sent to connector tasks without adding redundancy in configuration.
Public Interfaces
This feature will directly make changes to the SinkTask
SinkTaskContext
class with the addition of a new method and a new interface.
Method
This KIP will add a
...
getter method to the SinkTaskContext
class that will return a error reporter
object, and by default this method will return null. Sink connectors that wish to use an error reporter can
...
call this
...
method within their tasks.
The method
...
will look
...
the following:
...
private
BiConsumer<SinkRecord, Throwable> errorReporter =
null
;
/**
* Set the error reporter for this task.
*
* <p>The general usage pattern for this error reporter is to use this method to set it,
* and invoke its {@link accept(SinkRecord record, Throwable e)} method when an
* exception is thrown while processing a record in {@link put(Collection<SinkRecord> records)}
* to send this errant record to the error reporter.
*
* @param reporter The error reporter to send errant records to.
*/
public
void
errantRecordReporter(BiConsumer<SinkRecord, Throwable> reporter) {
// set the task's error reporter to the passed reporter
this
.errorReporter = reporter;
}
public
void
put(Collection<SinkRecord> records) {
for
(SinkRecord record: records) {
try
{
// attempt to send record to data sink
process(record);
}
catch
(Exception e) {
// send errant record to error reporter
errorReporter.accept(record, e);
}
}
}
Proposed Changes
Error Reporter Object
Kafka Connect will create a BiConsumer<SinkRecord, Throwable>
object to as the error reporter object. Along with the original errant sink record, the exception thrown will be sent to the error reporter to provide additional context. The only configurations exposed to the user and developer will be the following, taken from KIP-298:
...
Config Option
...
Description
...
Default Value
...
Domain
...
Code Block |
---|
public interface SinkTaskContext {
...
/**
* Get the reporter to which the sink task can report problematic or failed {@link SinkRecord}
* passed to the {@link SinkTask#put(Collection)} method. When reporting a failed record,
* the sink task will receive a {@link Future} that the task can optionally use to wait until
* the failed record and exception have been written to Kafka via Connect's DLQ. Note that
* the result of this method may be null if this connector has not been configured with a DLQ.
*
* <p>This method was added in Apache Kafka 2.6. Sink tasks that use this method but want to
* maintain backward compatibility so they can also be deployed to older Connect runtimes
* should guard the call to this method with a try-catch block, since calling this method will result in a
* {@link NoSuchMethodException} or {@link NoClassDefFoundError} when the sink connector is deployed to
* Connect runtimes older than Kafka 2.6. For example:
* <pre>
* ErrantRecordReporter reporter;
* try {
* reporter = context.failedRecordReporter();
* } catch (NoSuchMethodError | NoClassDefFoundError e) {
* reporter = null;
* }
* </pre>
*
* @return the reporter function; null if no error reporter has been configured for the connector
* @since 2.6
*/
default ErrantRecordReporter errantRecordReporter() {
return null;
}
} |
Interface
This KIP will add an ErrantRecordReporter
interface and will contain one method, report(SinkRecord record, Throwable error)
.
The interface will look like the following:
Code Block |
---|
/**
* Component that the sink task can use as it {@link SinkTask#put(Collection<SinkRecord>)}
* Reporter of problematic records and the corresponding problems.
*
* @since 2.6
*/
public interface ErrantRecordReporter {
/**
* Report a problematic record and the corresponding error to be written to the sink
* connector's dead letter queue (DLQ).
*
* <p>This call is asynchronous and returns a {@link java.util.concurrent.Future Future}.
* Invoking {@link java.util.concurrent.Future#get() get()} on this future will block until the
* record has been written and then return the metadata for the record
* or throw any exception that occurred while sending the record.
* If you want to simulate a simple blocking call you can call the <code>get()</code> method
* immediately.
*
* @param record the problematic record; may not be null
* @param error the error capturing the problem with the record; may not be null
* @return a future that can be used to block until the record and error are written
* to the DLQ
* @since 2.6
*/
Future<Void> report(SinkRecord record, Throwable error);
} |
Proposed Changes
Reporting
The error reporter interface will have one asynchronous reporting method. The method will accept the errant record and the exception thrown while processing the errant record, and return a Future<RecordMetadata>
. In order to handle the case where the connector is deployed to an older version of AK, when calling the method failedRecordReporter() to get the error reporter, the developer must catch the resulting NoClassDefError
or NoSuchMethodError
and set the reporter to null. Thus, when processing errant records, the developer should check if the reporter is null; if it is, then the developer should wrap the original exception in a ConnectException
and throw it. Records passed to the error reporter should be considered processed with respect to handling offsets, for example within the context of processing current offsets in preCommit(...)
.
The error reporter will use the same configurations as the dead letter queue in KIP-298 to avoid redundant configuration. There will be no additional configurations for the Producer
...
and AdminClient
under the hood aside from the
...
existing producer.
...
and admin.
...
configurations present in the worker configurations
...
and producer.override.
...
and admin.override.
...
configurations present in the connector configurations.
...
Serialization for the errant records will be done in the same manner as KIP-298.
Order of Operations
The order of operations will proceed like so:
...
Example Usage
The following is an example of how a sink task can use the error reporter and support connectors being deployed in earlier versions of the Connect runtime:
Code Block |
---|
private ErrantRecordReporter reporter;
@Override
public void start(Map<String, String> props) {
...
try {
reporter = context.errantRecordReporter(); // may be null if DLQ not enabled
} catch (NoSuchMethodException | NoClassDefFoundError e) {
// Will occur in Connect runtimes earlier than 2.6
reporter = null;
}
}
@Override
public void put(Collection<SinkRecord> records) {
for (SinkRecord record: records) {
try {
// attempt to send record to data sink
process(record);
} catch(Exception e) {
if (reporter != null) {
// Send errant record to error reporter
Future<Void> future = reporter.report(record, e);
// Optionally wait till the failure's been recorded in Kafka
future.get();
} else {
// There's no error reporter, so fail
throw new ConnectException("Failed on record", e);
}
}
}
} |
...
Synchrony
The error reporting functionality is
...
asynchronous, although tasks can use the resulting future to wait for the record and exception to be written to Kafka.
Guarantees
The Connect framework also guarantees that by the time preCommit(...)
is called on the task, the error reporter will have successfully and fully recorded all reported records with offsets at or before those passed to the preCommit
method. Sink task implementations that need more strict guarantees can use the futures returned by report(...)
to wait for confirmation that reported records have been successfully recorded.
Metrics
No new metrics will be added for the error reporter. Instead, the metrics detailed in KIP-298 for the dead letter queue will be used for the error reporter.
Errors Tolerance
The Errant Record Reporter will adhere to the existing DLQ error tolerance functionality. For example, if `errors.tolerance` is set to `ALL`, all errors will be tolerated; if the property is set to `NONE`, then the Errant Record Reporter will throw an exception detailing that the tolerance has been exceeded. Even if the developer chooses to catch and swallow any of these exceptions thrown during `report(...)`, the task is guaranteed to be killed following the completion of `put(...)`.
FileSinkTask Example
This KIP will update the FileSinkTask
example to use the new API, to demonstrate proper error handling with the ability to use it on older versions of Kafka Connect.
Metrics
The following metrics will used to monitor the error reporter:
...
Compatibility, Deprecation, and Migration Plan
Backwards Compatibility
...
This proposal is backward compatible such that existing sink connector implementations will continue to work as before. Developers can optionally modify sink connector implementations to use the new error reporting feature, yet still easily support installing and running those connectors in older Connect runtimes where the feature does not exist.
Moreover, to ensure that new connectors using this new method and interface can still be deployed on older versions of Kafka Connect, the developer should use a try catch block to catch the NoSuchMethodError
or NoClassDefFoundError
thrown by worker with an older version of AK.
Rejected Alternatives
- New library or interface: creating a separate library like
connect-reporter
will cause redundancy in configuration, and creating any new interface or API will limit backwards compatibility. Deploying a connector on an old version of connect will not be a seamless integration with the introduction of a new interface - Exposing
ErrorReporter
andProcessingContext
as public APIs: the main issue with this design is that the the API exposes packages withruntime
in them and package names cannot be changed. - Labeling as a dead letter queue:
...
- this is too specific of a label; using error reporter creates a more general contract of use case
- Batch error reporting: this would introduce the need for keeping track of order, and the increase in throughput doesn't seem to outweigh the added complication
- Creating a setter method in
SinkTask
that accepts an error reporter object: while this allows for backwards compatibility, it doesn't follow previous patterns of adding these types of methods toSinkTaskContext
and is not a very aesthetic addition to the interface - Creating an overloaded
put(...)
method that accepts an error reporter object and deprecating the originalput(...)
method: deprecating the original method can cause confusion on which method to implement and if the wrong method is implemented, it can cause backwards compatibility issues - Synchronous-only functionality: this limits developer control on functionality and traditionally a lot of functionality within Kafka Connect has had asynchronous functionality
- Using
Callback
rather thanFuture
: because a sink task's callback is called from the producer thread, it can risk a poorly written sink task callback killing the reporter's producer without necessarily failing the task