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: "Under Discussion"

Discussion thread: here

JIRA: here

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

Motivation

KafkaProducer is designed to be thread-safe and we encourage users to share a single producer instance across multiple threads[link]. These threads often need to send records to different topics. However, another important configuration—acks—is currently set at the producer level only.

As a result, users needing different acks settings for each topic must create additional producer instances instead of reusing the existing one and this approach requires 3x producer instances.

This is harmful for edge device(resource-constrained device) since users need to use a producer pool to handle different acks value. Additionally, this approach creates many idle producers if a sensor with a specific asks setting has no data for a while.

In this KIP, we propose adding topic-level acks, enabling users reuse a single KafkaProducer even when different topics require different acks settings. This change will reduce the need for multiple producers and minimize resource usage on edge devices.

Public Interfaces

We add a new config TOPIC_ACKS_CONFIG  and TOPIC_ACKS_DOC into ProducerConfig and define the format.

• Format  : acks.topic => acks.<TopicA>=<acks1>:acks.<TopicB>=<acks2>
• example: config.put(acks.topic, acks.money=-1:acks.temperature=1)

null

Proposed Changes

• Adding a new configuration in  ProducerConfig : acks.topic,  By setting this configuration item, users can customize the acks for specific topic.
• Behavior change:
  
  1. Attach topic-level acks to RecordAccumulator#TopicInfo.
  2. Return Map<Acks, List<ProducerBatch>> when RecordAccumulator#drainBatchesForOneNode is called.
  3. Finally, we can get the acks information and group same acks into List<ProducerBatch>> for a node in sender#sendProduceRequests and then send request.

Compatibility, Deprecation, and Migration Plan

• The public interface is new one so there are no compatibility issues.
• The ProduceRequest already contains an acks field so we don't need add any additional change at PRC-level [link].

Performance issue

• There is no performance issue since we will group the same acks batches to broker.
• producer request is asynchronous operation so we do not wait the response.

Test Plan

• Relevant unit tests and integration tests will be added to demonstrate the functionality.

Rejected Alternatives

• N/A