THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
| Table of Contents |
|---|
Status
Current state: Under Discussion Discarded
Discussion thread: here
JIRA: [
| Jira | ||||||
|---|---|---|---|---|---|---|
|
...
It seems that naming LogCleaner is somewhat misleading and LogComparator LogCompactor is more appropriate one. So LogCleaner and related classes/methods/configs should be renamed to Comparator 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.compaction.lag.ms |
| log.cleaner.threads | log.compactor.threads |
...
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.Apart from the configuration changes mentioned above, following Classes will be renamed.
Also, all variables, methods and documentation in the classes will be updated to reflect the new name changes. All related test-cases will be renamed as well.
...
...
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