[jira] [Commented] (GEODE-9824) AvailablePortHelper configures itself poorly in a test JVM

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ 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)