RFR: 8276139: TestJpsHostName.java not reliable, better to expand HostIdentifierCreate.java test

[Kevin Walls]

On Fri, 29 Oct 2021 11:29:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove a specific test which invokes jps on a fictional process, and can timeout and fail.
> Instead, add to the patterns used in open/test/jdk/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java which will perform the same test, that we can create a HostIdentifier using numeric values.

Hi,
The timeout is interesting, but not _very_ interesting... 8-)

My laptop fails quickly, with Linux under WSL, jps 12345 shows:

RMI Registry not available at 12345:1099
Exception creating connection to: 12345; nested exception is:
        java.net.SocketException: Network is unreachable (connect failed)
		
..and strace:
		
22089 connect(13, {sa_family=AF_INET6, sin6_port=htons(1099), inet_pton(AF_INET6, "::ffff:0.0.48.57", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)

That is not slow, although the test has already done what it needs to do (accept a numeric id) before it looks at the network.

But a different machine takes a long time, strace shows:

8384  connect(6, {sa_family=AF_INET6, sin6_port=htons(1099), inet_pton(AF_INET6, "::ffff:0.0.48.57", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28 <unfinished ...>	

..and we take 2 minutes+ to fail.  The test times out and is called a failure by jtreg.

ipv6 is kind of interesting as I'm not knowingly using it, but it is available on the interfaces in both cases.

That slow run passes if jtreg has e.g. -timeout argument... It needs 5m27s to pass here.
I have seen similar timings in the mach5 CI system.

20074 connect(6, {sa_family=AF_INET6, sin6_port=htons(37266), inet_pton(AF_INET6, "::ffff:0.0.48.57", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28 <unfinished ...>
...lots of time...
20074 <... connect resumed> )           = -1 ETIMEDOUT (Connection timed out)

No doubt these could be made to behave differently.  But as we have an existing test which does what is needed, and avoids network unpredictability, I think that's the right move here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6170