Status

Current state: 

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]

JIRA: Unable to render Jira issues macro, execution error.

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

This KIP tries to address the following issues in Kafka.

As part of KIP-82, the headers are added to Kafka ProducerRecord and ConsumerRecord.

As discussed in that KIP the headers provide lot of benefits especially metadata association with the record and propagating same along with record. These headers are very helpful to pass client metadata and unique Id for the record.

Once the record is sent i.e added to ProduceBatch, we get RecordMetaData along with callback to track. The RecordMetadata contains details like topic, partition, offset, timestamp etc. But there is no link on for which record this RecordMetadata belongs to.

For example in ProducerInterceptor we have an interface method onAcknowledgement(...) which is used to intercept the status of the record produced to kafka. It has  RecordMetadata as parameter. Since RecordMetaData doesn't contain headers information we have no insights on  for which record this RecordMetadata belongs to. Record headers will have record metadata like unique Id from client for each record.

If we add record headers to RecordMetaData, we can link record to metadata status i.e we can track what is the produce status and metadata for the given record.

Public Interfaces

Proposed Changes

Describe the new thing you want to do in appropriate detail. This may be fairly extensive and have large subsections of its own. Or it may be a few sentences. Use judgement based on the scope of the change.

Changes to RecordMetaData and FutureRecordMetaData to have headers information along with other metadata like topic, partition and offset etc.

public final class RecordMetadata {

    /**
     * Partition value for record without partition assigned
     */
    public static final int UNKNOWN_PARTITION = -1;

    private final long offset;
    ..........
    private final TopicPartition topicPartition;
    private final Header[] headers;

    private volatile Long checksum;

    public RecordMetadata(TopicPartition topicPartition, long baseOffset, long relativeOffset, long timestamp,
                          Long checksum, int serializedKeySize, int serializedValueSize, Header[] headers) {
        // ignore the relativeOffset if the base offset is -1,
        // since this indicates the offset is unknown
        this.offset = baseOffset == -1 ? baseOffset : baseOffset + relativeOffset;
        this.timestamp = timestamp;
        this.checksum = checksum;
        this.serializedKeySize = serializedKeySize;
        this.serializedValueSize = serializedValueSize;
        this.topicPartition = topicPartition;
        this.headers = headers;
    }
    ......

    /**
     * The headers of the record was sent to
     */

    public Header[] headers() {
        return this.headers;
    }


   ......
}

public final class FutureRecordMetadata implements Future<RecordMetadata> {

    private final ProduceRequestResult result;
    ..........
    private final Header[] headers;
    private volatile FutureRecordMetadata nextRecordMetadata = null;

    public FutureRecordMetadata(ProduceRequestResult result, long relativeOffset, long createTimestamp,
                                Long checksum, int serializedKeySize, int serializedValueSize, Time time, Header[] headers) {
        this.result = result;
        this.relativeOffset = relativeOffset;
        this.createTimestamp = createTimestamp;
        this.checksum = checksum;
        this.serializedKeySize = serializedKeySize;
        this.serializedValueSize = serializedValueSize;
        this.time = time;
        this.headers = headers;
    }

.......

}

2. In ProduceBatch add headers to futurerecordmetadta while appending record to the batch.

3. Add headers to RecordMetaData for send error scenarios also.

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users?

                 There is no impact

• If we are changing behavior how will we phase out the older behavior?

                  Older behavior does not change so no need to phase it out.

• If we need special migration tools, describe them here.

                 No special migration tools needed.

• When will we remove the existing behavior?

               We will keep the existing behavior.

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.