junrao commented on code in PR #20334:
URL: https://github.com/apache/kafka/pull/20334#discussion_r2535195749
##########
docs/upgrade.html:
##########
@@ -113,6 +113,35 @@ <h5><a id="upgrade_420_notable"
href="#upgrade_420_notable">Notable changes in 4
<li>
The <code>num.replica.fetchers</code> config has a new lower bound of
1.
</li>
+ <li>
+ Improvements have been made to the validation rules and default values
of LIST-type configurations
+ (<a href="https://cwiki.apache.org/confluence/x/HArXF";>KIP-1161</a>).
+ <ul>
+ <li>
+ LIST-type configurations now enforce stricter validation:
+ <ul>
+ <li>Null values are no longer accepted for most LIST-type
configurations, except those that explicitly
+ allow a null default value or where a null value has a
well-defined semantic meaning.</li>
+ <li>Duplicate entries within the same list are no longer
permitted.</li>
Review Comment:
> 1. Enforce the new lower bound at the API layer so existing cases that
seemingly have been working fine continue to work.
Not sure enforcing at the API layer is enough since some of the configs can
be changed through config files.
> 2. Automatically adjust the config to be at the new lower bound.
[KIP-1030](https://cwiki.apache.org/confluence/x/FAqpEQ) introduced the
following two breaking changes in 4.0.
remote.log.manager.copier.thread.pool.size
remote.log.manager.expiration.thread.pool.size
For both configs, the value -1 is no longer valid. -1 was introduced for
backward compatibility so that the value defaults to an old config
remote.log.manager.thread.pool.size, which will be deprecated. Once
remote.log.manager.thread.pool.size is removed, it's not clear what the value
-1 should be auto adjusted to. Perhaps the default value?
[KIP-1030](https://cwiki.apache.org/confluence/x/FAqpEQ) also proposed to
increase the lower bound for segment.ms / log.roll.ms (which is targeted for
5.0). Adjusting the config value automatically based on the new lower bound may
not be ideal. A user may depend on the original config value for some semantic
reasons (e.g. how long the data is kept). If the original value is no longer
valid, it's probably better to fail so that the user is aware of it.
> If we care that much about duplicate configs, we can simply remove the
duplication (there is no change in semantics) - why force the user to deal with
that?
I agree for this particular case, we could ignore the duplicates
automatically for the users.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
