Skip to content
This repository has been archived by the owner on Sep 26, 2019. It is now read-only.

[MINOR] no fixed ports in tests #340

Merged
merged 3 commits into from
Dec 1, 2018
Merged

Conversation

shemnon
Copy link
Contributor

@shemnon shemnon commented Nov 30, 2018

PR description

Some of our tests rely on fixed network ports being available to run
their test. Add code to choose OS assigned ephemeral ports in those
cases.

Some of our tests rely on fixed network ports being available to run
their test.  Add code to choose OS assigned ephemiral ports in those
cases.
public static int generateEphemiralPort() throws IOException {
try (final ServerSocket serverSocket = new ServerSocket(0)) {
return serverSocket.getLocalPort();
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is unreliable as the port may be used by a different process between this check to find a free port and actually opening the real socket (surprisingly common since the very next port typically assigned is this one). Peer discovery should be able to accept 0 as a port argument and provide a way to get the actual port used which is what we've moved other tests to.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are lots of chickens and eggs here. It may involve re-writing how the test works and have two agents talking to each other instead of one talking to itself. While we can have the agent bind to zero, it needs to be peer to itself.

Second, the risk of port re-use is smaller than the certainty of a running node on a default stopping this test.

I'll take a quick gander at a two-agent solution to this test.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A big concern for me is that this pattern spreads - we used to have a utility method like this and got a ton of intermittency from port conflicts because of it. I'm rather keen to avoid reintroducing the utility method since it has a tendency to spread in its usage. Plus given the number of port conflict problems we had with this approach in the past it doesn't seem to help much.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, the two agent pattern appears to have worked.

Approach #2, First enable "0" port in PeerDiscoveryAgent so it binds to
an open port.  Then change the test to use two PeerDiscoveryAgents

The change to zero is accomplished by populating the endpoint with
the actual bound socket instead of the value passed in.  If it is
zero the value will change otherwise it will be the value passed in.
Copy link
Contributor

@ajsutton ajsutton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Seems to be a much more realistic test now too.

@shemnon shemnon merged commit d2dcb46 into PegaSysEng:master Dec 1, 2018
@shemnon shemnon deleted the build_tweaks branch December 2, 2018 03:06
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants