This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • KIP-184: Rename LogCleaner and related classes to LogCompactor
Skip to end of metadata
Go to start of metadata

Status

Current state: Discarded

Discussion thread: here 

JIRA: [ KAFKA-1944 - Getting issue details... STATUS ]

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

Motivation

It seems that naming LogCleaner is somewhat misleading and LogCompactor is more appropriate one. So LogCleaner and related classes/methods/configs should be renamed to Compactor instead of Cleaner

Public Interfaces

log.cleaner.enable will be deprecated and eventually, it will be removed from the configuration. Going forward if log.cleanup.policy is set to compact then cleaner will be enabled implicitly.

Till the time this deprecated property will be there, if log.cleaner.enable config is set then its value will be considered while enabling compactor and a warning will be emitted mentioning, "This config is going to be removed in future and then compactor will be enabled based on the value of log.cleanup.policy"

 

Following old configuration will be deprecated and new renamed configuration will be introduced. 

Existing configurationNew configuration
log.cleaner.backoff.mslog.compactor.backoff.ms
log.cleaner.dedupe.buffer.sizelog.compactor.dedupe.buffer.size
log.cleaner.delete.retention.mslog.compactor.delete.retention.ms
log.cleaner.io.buffer.load.factorlog.compactor.io.buffer.load.factor
log.cleaner.io.buffer.sizelog.compactor.io.buffer.size
log.cleaner.io.max.bytes.per.secondlog.compactor.io.max.bytes.per.second
log.cleaner.min.cleanable.ratiolog.compactor.min.cleanable.ratio
log.cleaner.min.compaction.lag.mslog.compactor.min.lag.ms
log.cleaner.threadslog.compactor.threads


Proposed Changes

New renamed configuration will be introduced and existing configuration will be deprecated.
As proposed on JIRA, following approach will be considered while taking values.

0. Default value of the new config will be same as the deprecated config
1. If both deprecated and new config values are specified, log a WARN entry will be emitted and the new config value will be chosen.
2. If only one of them is specified, its value will be chosen.
3. If none of them are specified, then the default value, which should be the same, will be used.


Compatibility, Deprecation, and Migration Plan

Existing configuration will be deprecated first and then eventually it will be removed.

Rejected Alternatives

 

Reason for Discarding

As per the dicussion on mailing list. It seems that there are too many configuration changes required for this renaming. 

Also the LogCleaner terminology is quite old and many users have gotten used to it. There are no evidence of users getting confused because of the naming. 

So it seems that renaming will cause more troubles to the users, since there will be many configuraiton name changes. And it does not seems to be worth it

 

  • No labels