[IMPROVED] Routing: reduce chances of duplicate implicit routes #5602
Conversation
This file contains 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
This is an alternate approach to the PR #5484 from @wjordan. Using the code in that PR with the test added in this PR, I could still see duplicate routes (up to 125 in one of the matrix), and still had a data race (that could have easily be fixed). The main issue is that the increment happens in connectToRoute, which is running from a go routine, so there were still chances for duplicates. Instead, I took the approach that those duplicates were the result of way too many gossip protocols. Suppose that you have servers A and B already connected. C connects to A. A gossips to B that it should connect to C. When that happened, B would gossip to A the server C and C would gossip to A the server B, which all that was unnecessary. It would grow quite fast with the size of the cluster (that is, several thousands for a cluster size of 15 or so). Resolves #5483 Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
bruth
added a commit
that referenced
this pull request
Jul 30, 2024
Includes the following: * #5602 * #5672 * #5668 * #5607 * #5687 * #5695 * #5697 * #5704 * #5706 * #5709 * #5710 * #5713 * #5719 Some PRs specifically excluded: * #5707 — based on a 2.11 NRG PR * #5690 — continue to allow Go 1.20 for 2.10.x * Various other NRG PRs which are higher risk and destined for 2.11 instead
|
@kozlovic We noticed that |
kozlovic
added a commit
that referenced
this pull request
Aug 3, 2024
The PR#5602 solved the issue for typical seed setups, but it was found that the test `TestStressChainedSolicitWorks` would sometimes fail. This is a situation where we have S4->S3->S2->S1 and all servers start at the same type. This is not a typical setup, but still the regular gossip would allow the creation of the full mesh, so this PR helps in those situations. Related to #5602 Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
derekcollison
added a commit
that referenced
this pull request
Aug 3, 2024
#5746) The PR#5602 solved the issue for typical seed setups, but it was found that the test `TestStressChainedSolicitWorks` would sometimes fail. This is a situation where we have S4->S3->S2->S1 and all servers start at the same type. This is not a typical setup, but still the regular gossip would allow the creation of the full mesh, so this PR helps in those situations. Related to #5602 Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
neilalexander
added a commit
that referenced
this pull request
Aug 6, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is an alternate approach to the PR #5484 from @wjordan.
Using the code in that PR with the test added in this PR, I could still see duplicate routes (up to 125 in one of the matrix), and still had a data race (that could have easily be fixed). The main issue is that the increment happens in connectToRoute, which is running from a go routine, so there were still chances for duplicates.
Instead, I took the approach that those duplicates were the result of way too many gossip protocols. Suppose that you have servers A and B already connected. C connects to A. A gossips to B that it should connect to C. When that happened, B would gossip to A the server C and C would gossip to A the server B, which all that was unnecessary. It would grow quite fast with the size of the cluster (that is, several thousands for a cluster size of 15 or so).
Resolves #5483
Signed-off-by: Ivan Kozlovic ivan@synadia.com