[
https://issues.apache.org/jira/browse/KAFKA-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865033#comment-17865033
]
Ksolves India Limited commented on KAFKA-6939:
----------------------------------------------
The configuration
[log.message.timestamp.difference.max.ms|http://log.message.timestamp.difference.max.ms/]
has been deprecated. As per
[KIP-937|https://cwiki.apache.org/confluence/display/KAFKA/KIP-937%3A+Improve+Message+Timestamp+Validation],
two new configurations,
[log.message.timestamp.before.max.ms|http://log.message.timestamp.before.max.ms/]
and
[log.message.timestamp.after.max.ms|http://log.message.timestamp.after.max.ms/],
have been introduced to replace it.
We may make the change for the previous versions but the config will be removed
from future versions. But I guess we can skip this change. Thoughhts?
> Change the default of log.message.timestamp.difference.max.ms to 500 years
> --------------------------------------------------------------------------
>
> Key: KAFKA-6939
> URL: https://issues.apache.org/jira/browse/KAFKA-6939
> Project: Kafka
> Issue Type: Improvement
> Components: log
> Reporter: Badai Aqrandista
> Priority: Minor
>
> If producer incorrectly provides timestamp in microsecond (not in
> millisecond), the record is accepted by default and can cause broker to roll
> the segment files continuously. And on a heavily used broker, this will
> generate a lot of index files, which then causes the broker to hit
> `vm.max_map_count`.
> So I'd like to suggest changing the default for
> log.message.timestamp.difference.max.ms to 15768000000000 (500 years * 365
> days * 86400 seconds * 1000). This would reject timestamp in microsecond from
> producer and still allow most historical data to be stored in Kafka.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
