Status

Current state: Accepted

Vote thread: here 

Discussion thread: here 

JIRA: KAFKA-13610 - Getting issue details... STATUS

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

Motivation

log.cleaner.enable  is a longstanding configuration, but it has become essentially meaningless. This configuration should be enabled if users have any compacted topics. Still, topic compaction becomes ineffective if the configuration is disabled, and users remain unaware that compaction is disabled when configuring a compacted topic.

Additionally, this configuration leads to unnecessarily complex code. Currently, when log.cleaner.enable=false , the LogCleaner is set to null, it requires numerous null checks throughout the codebase. Ideally, we should unconditionally create the log cleaner object in the LogManager constructor, even if we never start it. Removing the log.cleaner.enable  configuration could simplify the code and eliminate these many null checks.

Public Interfaces

N/A

Proposed Changes

We propose deprecating log.cleaner.enable  configuration and completely remove it in Kafka 5.0.

Since the user couldn't disable the log cleaner, the related configuration, `log.cleaner.threads`, will have a lower bound of 1.

Compatibility, Deprecation, and Migration Plan

We will deprecate this configuration and completely remove it from Kafka 5.0.
After we deprecate it, we should document that users should no longer set this configuration to `false` to prepare for future removal.
Users could still configure this configuration freely before Kafka 5.0.

Test Plan

N/A

Rejected Alternatives

N/A