cheeeee commented on PR #23928:
URL: https://github.com/apache/kafka/pull/23928#issuecomment-6356602013
Test notes, continued: the same on macOS 26.7 (Apple Silicon, JDK 17),
with the brokers as local processes, on 73fc46a880 and on trunk
d18f93f985.
* Persistent media error: broker 1's log directory is on a disk image,
and a 1 MiB band of the image in the middle of the segment is made
unreadable, so the kernel fails reads of it with EIO. macOS ejects
the image right after, so every later read fails too. Over TLS,
trunk re-reads the region on the scheduler, which fails; this change
offlines the directory without a re-read. Over PLAINTEXT both
re-read, and the re-read fails. The directory goes offline in all
four runs, and the consumer reads all 20000 records from broker 2.
* Error gone on the next read, injected by an interposer on `pread`
and `sendfile` (`DYLD_INSERT_LIBRARIES`, the macOS stand-in for
`strace -e inject`): as on Linux, trunk re-reads 8 MiB after each
failure and keeps the directory online; over TLS this change
offlines it; over PLAINTEXT both keep it online.
* Disconnects, 3 TLS consumers killed mid-fetch for 5 minutes, about
180 times: trunk 19497 reads of segment files on the scheduler,
636 MB; this change none.
On macOS a read fails before the unreadable bytes: with the band at
positions 3129344 to 4177919, `pread` failed at 2129920, and
`sendfile` at 2736128 after reporting progress up to that page. So
`FileReadException.position()` is where the failed read started,
which is not necessarily where the medium failed.
--
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]
