Hi,
I support changing constraints for mentioned settings.
I've noticed that first producing big messages, and then setting
`segment.bytes` to low value causes unwanted consequences. I did not notice
that it would delete all the records, but I did not set it to one, but
instead the case is
Hi all,
There are also message.max.bytes, replica.fetch.max.bytes and their
derivatives requires a constraint on their maximum value as the maximum
total memory on the instance. Otherwise, these could cause out of memory
errors on the instance.
Do you think this is in scope here as well?
On
Hi, Divij.
This isn't about config default value/constraint change though, I found
there's a behavior discrepancy in max.block.ms config, which may cause
breaking change if we change the behavior.
The detail is described in the ticket:
https://issues.apache.org/jira/browse/KAFKA-16372
What do
One use case I see for setting the `segment.bytes` to 1 is to delete all
the records from the topic.
We can mention about it in the doc to use the `kafka-delete-records` API
instead.
On Wed, Mar 13, 2024 at 6:59 PM Divij Vaidya
wrote:
> + users@kafka
>
> Hi users of Apache Kafka
>
> With the
+ users@kafka
Hi users of Apache Kafka
With the upcoming 4.0 release, we have an opportunity to improve the
constraints and default values for various Kafka configurations.
We are soliciting your feedback and suggestions on configurations where the
default values and/or constraints should be
Thanks for the discussion folks. I have started a KIP
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1030%3A+Change+constraints+and+default+values+for+various+configurations
to keep track of the changes that we are discussion. Please consider this
as a collaborative work-in-progress KIP and
I think it's a great idea to raise a KIP to look at adjusting defaults and
minimum/maximum config values for version 4.0.
As pointed out, the minimum values for segment.ms and segment.bytes don't
make sense and would probably bring down a cluster pretty quickly if set
that low, so version 4.0 is
hey guys,
Regarding to num.recovery.threads.per.data.dir: I agree, in our company we
use the number of vCPUs to do so as this is not competing with ready
cluster traffic.
On Wed, 13 Mar 2024 at 09:29, Luke Chen wrote:
> Hi Divij,
>
> Thanks for raising this.
> The valid minimum value 1 for
Hi Divij,
Thanks for raising this.
The valid minimum value 1 for `segment.ms` is completely unreasonable.
Similarly for `segment.bytes`, `metadata.log.segment.ms`,
`metadata.log.segment.bytes`.
In addition to that, there are also some config default values we'd like to
propose to change in v4.0.
