[
https://issues.apache.org/jira/browse/SOLR-18098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18096670#comment-18096670
]
Serhiy Bzhezytskyy commented on SOLR-18098:
-------------------------------------------
Hit this test failing deterministically on main with seed 6FA33BD8BF6D0D4C:
IndexFetcherPacketProtocolTest > testSingleByte FAILED
java.lang.AssertionError: fetchPackets return code mismatch expected:<0> but
was:<1>
The test stages a file into the index dir and reads it back through the
replication fetch path. When the randomized directory factory is an ephemeral
(RAM) one like ByteBuffersDirectory, the staged file isn't visible to the fetch
path, so the server side throws NoSuchFileException and fetchPackets returns
non-zero. With an FS factory it passes, which is why it looks flaky.
TestReplicationHandler already forces an FS factory via useFactory(null) for
the same reason.
PR: https://github.com/apache/solr/pull/4642
> Replication fails with EOFException for files with sizes that are exact
> multiples of PACKET_SZ (1 MB)
> -----------------------------------------------------------------------------------------------------
>
> Key: SOLR-18098
> URL: https://issues.apache.org/jira/browse/SOLR-18098
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
> Affects Versions: 9.7, 9.8, 9.8.1, 9.10, 9.9.0, 9.10.1
> Reporter: Shubham Ranjan
> Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> h2. Problem
> Replication fails with {{EOFException}} when transferring files whose sizes
> are exact multiples of 1 MB (e.g., 1 MB, 2 MB, 63 MB, etc.).
> {code:java}
> ERROR org.apache.solr.handler.IndexFetcher File _5xc54.cfs downloaded in
> ERROR, downloaded 66060288 of 66060288 bytes
> Caused by: java.io.EOFException
> at
> org.apache.solr.handler.IndexFetcher$FileFetcher.fetchPackets(IndexFetcher.java:1767)
> {code}
> File size: 66,060,288 bytes = 63 MB exactly
> h2. Root Cause
> Packet protocol mismatch between leader (sender) and follower (receiver):
> - Leader sends files in 1 MB packets with checksums
> - For files that are exact MB multiples, leader sends a final zero-length
> packet WITH an 8-byte checksum
> - Follower's bug: when it reads {{packetSize = 0}}, it skips to the next
> iteration WITHOUT consuming the checksum
> - This causes stream misalignment - next read interprets checksum bytes as
> packet size, then fails
> Buggy code in {{IndexFetcher.java}} lines 1760-1761:
> {code:java}
> if (packetSize <= 0) {
> continue; // BUG: Does not consume 8-byte checksum, misaligns stream
> }
> {code}
> h2. Impact
> Replicas cannot recover when affected files exist
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
