On Fri, 29 Oct 2021 11:29:32 GMT, Kevin Walls <kev...@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

Reply via email to