Dale Emery created GEODE-9824:
---------------------------------
Summary: 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
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)
