root
/
kafka
mirror of https://github.com/apache/kafka.git
1
0
Fork 0
Code Issues Actions 4 Packages Projects Releases Wiki Activity

MINOR: Use `firstTimestamp` instead of `baseTimestamp` in docs (#8584) 

In the docs, the `baseTimestamp` term is used when `firstTimestamp` is defined in the on-disk format and implementation.

Reviewers: Jason Gustafson <jason@confluent.io>
This commit is contained in:
Jorge Esteban Quilcate Otoya 2020-05-01 22:43:47 +01:00 committed by GitHub
parent fd095aaafd
commit 4803c779de
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/implementation.html
View File

@ -67,7 +67,7 @@
<p>On compaction: unlike the older message formats, magic v2 and above preserves the first and last offset/sequence numbers from the original batch when the log is cleaned. This is required in order to be able to restore the <p>On compaction: unlike the older message formats, magic v2 and above preserves the first and last offset/sequence numbers from the original batch when the log is cleaned. This is required in order to be able to restore the
producer's state when the log is reloaded. If we did not retain the last sequence number, for example, then after a partition leader failure, the producer might see an OutOfSequence error. The base sequence number must producer's state when the log is reloaded. If we did not retain the last sequence number, for example, then after a partition leader failure, the producer might see an OutOfSequence error. The base sequence number must
be preserved for duplicate checking (the broker checks incoming Produce requests for duplicates by verifying that the first and last sequence numbers of the incoming batch match the last from that producer). As a result, be preserved for duplicate checking (the broker checks incoming Produce requests for duplicates by verifying that the first and last sequence numbers of the incoming batch match the last from that producer). As a result,
it is possible to have empty batches in the log when all the records in the batch are cleaned but batch is still retained in order to preserve a producer's last sequence number. One oddity here is that the baseTimestamp it is possible to have empty batches in the log when all the records in the batch are cleaned but batch is still retained in order to preserve a producer's last sequence number. One oddity here is that the firstTimestamp
field is not preserved during compaction, so it will change if the first record in the batch is compacted away.</p> field is not preserved during compaction, so it will change if the first record in the batch is compacted away.</p>
<h5><a id="controlbatch" href="#controlbatch">5.3.1.1 Control Batches</a></h5> <h5><a id="controlbatch" href="#controlbatch">5.3.1.1 Control Batches</a></h5>