tusharsaini18899 opened a new pull request, #23303: URL: https://github.com/apache/kafka/pull/23303
## Summary Fixes https://issues.apache.org/jira/browse/KAFKA-21000 When `log.preallocate=true`, a new log segment is created at the configured initial file size. The physical file is larger than the logical data until `FileRecords.trim()` truncates it to `sizeInBytes()` on segment roll or close. `FileRecords.close()` previously called `flush()` before `trim()`. That fsync persisted message data but not the smaller file length set by `truncate()`, because truncation happened after the fsync. If the broker shut down cleanly and the process crashed before the OS flushed file metadata, the on-disk `.log` file could still report the preallocated length. On restart, recovery is skipped for a clean shutdown, so `readNextOffset()` can scan past the valid records into uninitialized/zero-filled bytes and fail. This is the same class of issue as https://issues.apache.org/jira/browse/KAFKA-20979, which fixed index resize durability on shutdown in `AbstractIndex.close()`. Reorder `FileRecords.close()` to trim before flush so `channel.force(true)` includes the truncated file length. Preallocation timing and trim on segment roll are unchanged; only shutdown durability of the trimmed size is fixed. ## Testing Added `FileRecordsTest.testCloseFlushesAfterTrim` to verify that `close()` truncates the channel and calls `force(true)` after trimming. Existing `testPreallocateClearShutdown` continues to verify that a preallocated file is truncated to the size of valid data after close and reopen. ```bash ./gradlew clients:test --tests org.apache.kafka.common.record.internal.FileRecordsTest -- 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]
