RFR(S): 8195809: [TESTBUG] jps and jcmd -l support for Docker containers is not tested

Bob Vandette bob.vandette at oracle.com
Tue Jul 30 15:12:26 UTC 2019


http://cr.openjdk.java.net/~mseledtsov/8195809.00/test/lib/jdk/test/lib/containers/docker/Common.java.sdiff.html

In findPidFromJcmdOutput, what if there are multiple processes with the same name running?
Isn’t it possible that multiple different test runs are occurring on the same host?  This might cause
intermittent failures.

A safer alternative might be to get the container id and then run docker inspect.

% docker inspect -f '{{.State.Pid}}’ cfc6fea3d152
4999

You could also create a random number and pass that as an argument to SimpleLoop and
then scan the matching processes for that argument.


I assume you’ll be cleaning or commenting out the debugging output in all files.

Bob.


> On Jul 29, 2019, at 11:46 PM, mikhailo.seledtsov at oracle.com wrote:
> 
> Please review this change that:
>  - adds test case for "jcmd -l" and "jcmd <pid> help" where jcmd is executed on a host/node outside the container,
>    while a targeted JVM is running inside a container
>  - factors out some common functionality to DockerTestUtils and docker.Common
> 
> Please note:
>  - the "jcmd -l" works in this configuration, however the JCMD's and Target's username and UID have to match
>    (per design)
>  - the "jcmd help", "jcmd JFR.start" or any other JCMD command besides "jcmd -l" does not work in this configuration
>    (Filed "JDK-8228343: JCMD and attach fail to work across Linux Container boundary")
>    The test case is commented out, however can be used for reproducing the issue, and will be enabled
>    once the bug is fixed.
> 
> 
>    JBS: https://bugs.openjdk.java.net/browse/JDK-8195809
>    Webrev: http://cr.openjdk.java.net/~mseledtsov/8195809.00/
>    Testing:
>      - ran the new test multiple times on Linux-x64
>      - ran TestJCMDWithSideCar multiple times on Linux-x64
>      - ran all Docker/Container tests (HotSpot and JDK)
>    All PASS
> 
> Thank you,
> Misha
> 



More information about the hotspot-runtime-dev mailing list