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 configuration | New configuration |
|---|---|
| log.cleaner.backoff.ms | log.compactor.backoff.ms |
| log.cleaner.dedupe.buffer.size | log.compactor.dedupe.buffer.size |
| log.cleaner.delete.retention.ms | log.compactor.delete.retention.ms |
| log.cleaner.io.buffer.load.factor | log.compactor.io.buffer.load.factor |
| log.cleaner.io.buffer.size | log.compactor.io.buffer.size |
| log.cleaner.io.max.bytes.per.second | log.compactor.io.max.bytes.per.second |
| log.cleaner.min.cleanable.ratio | log.compactor.min.cleanable.ratio |
| log.cleaner.min.compaction.lag.ms | log.compactor.min.lag.ms |
| log.cleaner.threads | log.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