Strategies added to FreePort for how to pick ports #3
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
FreePort was quite inflexible in how it picked ports. If multiple threads, or processes, were concurrently trying to look for free ports in a given range there is a high likelihood of collision where they both think a port is free then race to bind to it. This change adds strategies for how to pick the ports. The LinearFreePortStrategy reflects the old strategy of linearly walking the port range and trying each port. The RandomizedFreePortStrategy is a new strategy of repeatedly trying ports in a given range in order to avoid collisions. This doesn't remove the race condition as theoretically the same situation can occur with the RandomizedFreePortStrategy as the free port is never secured. However, it does mitigate against it and reduce the likelihood of collisions over a big enough range.
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.
FreePort was quite inflexible in how it picked ports. If multiple
threads, or processes, were concurrently trying to look for free ports
in a given range there is a high likelihood of collision where they both
think a port is free then race to bind to it.
This change adds strategies for how to pick the ports.
The LinearFreePortStrategy reflects the old strategy of linearly
walking the port range and trying each port.
The RandomizedFreePortStrategy is a new strategy of repeatedly trying
ports in a given range in order to avoid collisions.
This doesn't remove the race condition as theoretically the same
situation can occur with the RandomizedFreePortStrategy as the free port
is never secured. However, it does mitigate against it and reduce the
likelihood of collisions over a big enough range.