[
https://issues.apache.org/jira/browse/GEODE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-9824:
------------------------------
Description:
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.
was:
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.
> 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
>
> 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)
