Status

Current state: Under Discussion

Discussion thread: here

JIRA: KAFKA-13365

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

Motivation

As of 3.0.0, the user can configure the client (i.e., producer, consumer, and admin) settings used by MirrorMaker 2 with {cluster}.[producer|consumer|admin].<configuration-property> syntax. The problem is that only the common client settings like bootstrap servers, SSL configurations, etc., are configurable. For this reason, the producer-specific options or consumer-only settings are not changeable - that is, the user configurations are silently ignored, dislike to the documentation.

us-east.producer.acks = all  // ignored
us-west.consumer.max.poll.interval.ms = 120000 // also ignored

(Note: for the proof, see here.)

Because of that, those values are always fixed to the defaults and it causes some serious problems of MirrorMaker 2's functionality, like:

• Case 1: Since the producer's acks configuration is fixed to its default, '1', the replicated message may be lost if the leader broker crashes before the record is replicated.
• Case 2: Since the consumer's max.poll.interval.ms configuration is fixed to its default, 5 minutes, we can't reduce the time for rebalancing.

At first glance, this problem looks like a simple bug. However, this problem is more complicated than expected. The documentation states:

MirrorMaker is based on the Kafka Connect framework. Any Kafka Connect, source connector, and sink connector settings as described in the documentation chapter on Kafka Connect can be used directly in the MirrorMaker configuration, without having to change or prefix the name of the configuration setting.

Most of the default Kafka Connect settings work well for MirrorMaker out-of-the-box, with the exception of tasks.max.

It raises the following issues:

1. As of present, Kafka connect allows the users to override the client settings with [producer|consumer].override.<configuration-property> property if connector.client.config.override.policy is All (default). However, MirrorMaker 2 does not support it. This is not only inconsistent but also confusing for the users.
2. Dislike the other connectors, MirrorMaker 2 supports standalone mode, which lacks connector.client.config.override.policy; then, how can we deal with [producer|consumer].override.<configuration-property> in standalone mode?
3. No preference is defined between [producer|consumer].override.<configuration-property> and MirrorMaker 2 specific, {cluster}.[producer|consumer|admin].{configuration-property} syntax.

For the reasons above, this problem can't be fixed by simply filling up the omitted gaps; it requires finding a reasonable configuration scheme that is simple and consistent with both Kafka Connect and MirrorMaker 2 specific client configuration syntax.

Public Interfaces

This proposal does not introduce any new public interface or configurable settings; it only makes the existing ones (which are currently ignored by MirrorMaker 2) working by providing consistent, easy-to-understand configuration rules.

Proposed Changes

Here are the new rules for client config overriding policy:

1. MirrorMaker 2 specific syntax precedes Kafka Connect standard; that is, {cluster}.[producer|consumer].<configuration-property> always overrides [producer|consumer].override.<configuration-property>.
2. If MirrorMaker 2 is running in standalone mode, it fallbacks to the default value of connector.client.config.override.policy, i.e., All.
3. If connector.client.config.override.policy is not set to All, all [producer|consumer].override.<configuration-property> values are ignored.

The reasoning about the above rules will be discussed in Rejected Alternatives section.

Compatibility, Deprecation, and Migration Plan

The users without any specific overrides will not experience a change. But those who are trying to override the clients' defaults will see the configurations are now working.

Rejected Alternatives

Don't support [producer|consumer].override.<configuration-property> syntax

It not only breaks the consistency with the other connectors but also contradicts what the current documentation states.

Support [producer|consumer].override.<configuration-property> but not allow it in standalone mode

In this case, the configuration that works in connector mode does not work in standalone mode - breaking consistency between two modes.

Make [producer|consumer].override.<configuration-property> preferable to MirrorMaker 2 specific configurations

This approach breaks the consistency between producer/consumer/admin, since there is no admin.override.<configuration-property> configuration. (Please note that [producer|consumer].override.<configuration-property> is allowed just for the consistency with Kafka Connect standard; using this syntax is not recommended.)

Rejecting all the possible alternatives above, only the rules described in the Proposed Changes section remain.