[
https://issues.apache.org/jira/browse/GEODE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17450724#comment-17450724
]
ASF subversion and git services commented on GEODE-9824:
--------------------------------------------------------
Commit 8387def5b5604932573cb9ebaacbb3b0f6e00da9 in geode's branch
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8387def ]
GEODE-9824: Initialize AvailablePortHelper safely (#7129)
PROBLEMS
- In test JVMs, `AvailablePortHelper` initialized its next candidate
port by selecting a random port within the available port range. This
often caused the test JVM's first few candidates to overlap with the
first few candidates of a child VM.
- `AvailablePortHelper` updated its next candidate port in non-atomic
way, making it possible for multiple threads to receive the same port
number.
SOLUTION
Change `AvailablePortHelper` to:
- Initialize its next candidate port to `AVAILABLE_PORT_LOWER_BOUND`
instead of randomly selecting an initial candidate.
- Update its next candidate port atomically by calling
`AtomicInteger.getAndUpdate(...)`.
> AvailablePortHelper configures itself poorly in a test JVM
> ----------------------------------------------------------
>
> Key: GEODE-9824
> URL: https://issues.apache.org/jira/browse/GEODE-9824
> Project: Geode
> Issue Type: Bug
> Components: tests
> Affects Versions: 1.15.0
> Reporter: Dale Emery
> Assignee: Dale Emery
> Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> In the test JVM, `AvailablePortHelper` initializes its "next port to check"
> to a randomly selected port. That randomly selected port might be one of the
> ones that a child VM will check early.
> Here's a problematic sequence of events:
> # In the test JVM, `AvailablePortHelper` learns that the range of ports
> available to it is (say) 23750–24166. It randomly selects one of those as its
> "next port to check." Let's suppose it randomly picks 23854 as its starting
> port.
> # The test starts vm0. In vm0 `AvailablePortHelper` initializes its "next
> port to check" by computing it based on its VM number. For the given
> available port range (23750–24166), vm0 will *always* start at 23854.
> # At this point, both the test JVM and child vm0 have the exact same "next
> port to check." Trouble is looming.
> # The test requests a port in the test JVM, and gets the randomly selected
> one: 23854. It doesn't bind to this port yet. Later it will try to start a
> server on this port in vm1. Trouble is fast approaching.
> # The test invokes `AvailablePortHelper` in vm0, and gets vm0's starting
> port: 23854. The test then starts a server, which binds to that port.
> # At this point, the test JVM thinks it has reserved the port, but vm0 has
> bound to it. Trouble is imminent.
> # The test tries to start a server in vm1, using the port it believes it
> reserved. Trouble has arrived. The operation fails because the port is
> already in use.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
