...

public static boolean CONSUMER_GROUP_AWARE_TRANSACTION = "consumer.group.aware.transaction"; // default to false

When set to true and exactly-once is turned on, Kafka Streams application will choose to use single producer per thread.

Example

Below we provide an example of a simple read-process-write loop with consumer group-aware EOS processing.

...

This is a server-client integrated change, and it's required to upgrade the broker first with `inter.broker.protocol.version` to the latest. Any produce request with higher version will automatically get fenced, because we will use the same transaction id for different topic partitions at the same time (breaking EOS), while losing transaction status tracking once we switched coordinator location. Once Once server is upgraded, an existing application could opt to use this new feature by upgrading to latest version and either change producer syntax (non-stream app) or set `consumer.group.aware.transaction` to true (stream app). Since the transaction.id will be reused and different from previous one and transaction coordinator might be changed, this upgrade is not guaranteed to retain consistent commit log on the new group coordinator located broker.

Rejected Alternatives

• Producer Pooling:
• Producer support multiple transactional ids:
• Tricky rebalance synchronization:

...