Hi Kafka developers,

KIP-32 describes LogAppendTime as monotonically increasing. However, the 
current implementation stamps records using the active leader’s local clock.

After a leader election, the new leader’s clock may be behind the previous 
leader’s clock. In that case, newly appended records can receive a lower 
LogAppendTime than preceding records in the partition.

A possible fix is for each partition leader to select:

Plain text

max(current broker time, previous LogAppendTime)



The previous value can be recovered from the replicated log tail and maintained 
across follower appends, restart, truncation, and leader promotion. This 
guarantees nondecreasing timestamps without forcing a one-millisecond increase 
for every append.

Would this be considered a correctness fix completing KIP-32’s intended 
monotonicity guarantee, or would the observable timestamp behavior require a 
follow-up KIP?

KIP-32:

https://cwiki.apache.org/confluence/display/KAFKA/KIP-32+-+Add+timestamps+to+Kafka+message

Current assignment logic:

https://github.com/apache/kafka/blob/trunk/storage/src/main/java/org/apache/kafka/storage/internals/log/LogValidator.java

Thanks,

Alexander

Reply via email to