[
https://issues.apache.org/jira/browse/KAFKA-13610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
TengYao Chi updated KAFKA-13610:
--------------------------------
Description:
It's odd that things like the number of log cleaner threads are configurable,
but not whether it is on or off. We should make log.cleaner.enable dynamically
configurable to close this gap.
Additionally, from a code point of view, we should unconditionally create the
log cleaner object in the LogManager constructor even if we never start it.
This would simplify the code and eliminate many null checks.
Updated:
The `log.cleaner.enable` configuration should be removed because it has become
meaningless while creating unnecessary code complexity. Though historically
important, it now causes confusion as users remain unaware that disabling this
setting renders topic compaction ineffective. The configuration forces
developers to implement numerous null checks throughout the codebase, as the
LogCleaner is set to null when disabled. A more elegant solution would be
unconditionally creating the LogCleaner object in the LogManager constructor,
even if never started, thus simplifying the code architecture and improving
system reliability.
was:
It's odd that things like the number of log cleaner threads are configurable,
but not whether it is on or off. We should make log.cleaner.enable dynamically
configurable to close this gap.
Additionally, from a code point of view, we should unconditionally create the
log cleaner object in the LogManager constructor even if we never start it.
This would simplify the code and eliminate many null checks.
> Remove `log.cleaner.enable` and set lower bound 1 to `log.cleaner.threads`
> --------------------------------------------------------------------------
>
> Key: KAFKA-13610
> URL: https://issues.apache.org/jira/browse/KAFKA-13610
> Project: Kafka
> Issue Type: Improvement
> Reporter: Colin McCabe
> Assignee: TengYao Chi
> Priority: Major
> Labels: kip
> Fix For: 5.0.0
>
>
> It's odd that things like the number of log cleaner threads are configurable,
> but not whether it is on or off. We should make log.cleaner.enable
> dynamically configurable to close this gap.
> Additionally, from a code point of view, we should unconditionally create the
> log cleaner object in the LogManager constructor even if we never start it.
> This would simplify the code and eliminate many null checks.
>
> Updated:
> The `log.cleaner.enable` configuration should be removed because it has
> become meaningless while creating unnecessary code complexity. Though
> historically important, it now causes confusion as users remain unaware that
> disabling this setting renders topic compaction ineffective. The
> configuration forces developers to implement numerous null checks throughout
> the codebase, as the LogCleaner is set to null when disabled. A more elegant
> solution would be unconditionally creating the LogCleaner object in the
> LogManager constructor, even if never started, thus simplifying the code
> architecture and improving system reliability.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
