Repository navigation
SOLR-11475: Endless loop and OOM in PeerSync - #5082
Open
nick-boss-tech wants to merge 7 commits into
Open
nick-boss-tech wants to merge 7 commits into
nick-boss-tech wants to merge 7 commits into
Conversation
…n with opposite signs Hypothetical, unrun regression test; see SOLR-11475-TESTING.md.
With the version pair as the only entries, the walk reaches the range branch with otherUpdatesIndex at the end of the other list, and the old code fails on an index error instead of looping. Surrounding the pair with matching versions above and below makes the pre-fix failure the documented endless loop appending ranges until it runs out of memory. Assertions are unchanged.
…nly behavior The comment said the old code fails on an index error instead of looping when the sign-mismatched pair is the only entry. Tracing the base loop shows it loops endlessly there too, adding the same range string on every pass until memory runs out.
nick-boss-tech
marked this pull request as ready for review
October 9, 2026 23:26
nick-boss-tech
force-pushed
the
solr-11475-submit
branch
from
October 10, 2026 00:27
0de48e4 to
2299472
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 AI text below 🤖 (posted on behalf of Nick Shanin)
https://issues.apache.org/jira/browse/SOLR-11475
What happens today
PeerSync loops forever when both replicas hold the same version with opposite signs.
PeerSync compares its own recent updates with the versions another replica reports. The same version can appear on both sides with opposite signs: an add on one side, a delete on the other. The comparison loop then never moves past that pair. It keeps adding the same range string until memory runs out (loop).
What this change does
The loop steps past a version that appears on both sides with opposite signs.
When the two absolute values match, the loop moves both positions down one step and requests nothing for that pair (new branch). The other branches of the loop are unchanged (loop).
Proof
Five PeerSync test classes pass with this change. A run without the fix is inconclusive, because the old code never ends on this input.
PeerSyncTest,PeerSyncWithLeaderTest,PeerSyncWithBufferUpdatesTest,PeerSyncWithIndexFingerprintCachingTest, andPeerSyncWithLeaderAndIndexFingerprintCachingTest. Five tests in total, 0 failures.PeerSyncWithLeaderTestdeclares no test method of its own and runs thetest()ofPeerSyncTest.PeerSyncWithLeaderAndIndexFingerprintCachingTestruns thetest()ofPeerSyncWithIndexFingerprintCachingTest, which is a separate class.testHandleVersionsWithRangesSameVersionDifferentSign. It runs fromtest()inPeerSyncTestthroughhandleVersionsWithRangesTests(), so it runs inPeerSyncTestand inPeerSyncWithLeaderTest. It runs the walk on a thread and fails if the walk has not ended after 30 seconds.A choice to check
The loop steps over the pair and does not request it.
The other route requests the other side's version of that update, so this replica fetches it. This branch steps over the pair instead. The cost is that this replica does not fetch the other side's version through this walk.
Was stepping over the pair the right call, or should the other side's version be requested?
Limits
The check calls the PeerSync helper directly, with one set of versions.
Changelog:
changelog/unreleased/SOLR-11475-peersync-version-ranges-loop.ymlAI assistance
AI agents assisted with research, implementation, review, and drafting. Nick Shanin directed the work and takes responsibility for this contribution.