On 3/13/18 10:54 PM, David Holmes wrote:
Hi Daniil,
On 14/03/2018 3:26 PM, Daniil Titov wrote:
Please review the changes that fix intermittent timeout failure of
serviceability/dcmd/framework/* tests.
The problem here is that these tests invoke jcmd in different ways
and one of such ways is when a main class is passed to the jcmd as a
VM identifier. The main class for jtreg test is
com.sun.javatest.regtest.agent.MainWrapper and in some cases more
than one test are running in parallel and there are multiple Java
processes with com.sun.javatest.regtest.agent.MainWrapper as a main
class . When it happens jcmd iterates over all Java processes that
match the condition (the main class equals to
com.sun.javatest.regtest.agent.MainWrapper) and executes the command
for each of them. That results in the jcmd invokes the given command
multiple times and attaches to Java processes not related to the
current test.
It's good to finally find the root cause of the problem!
The fix makes serviceability/dcmd/framework/* tests non-concurrent to
ensure that they don't interact with other tests.
This seems more of a workaround than a fix - though I don't know
whether there is a way to distinguish multiple VMs all running what
appears to be the same main class.
The three tests are all intentionally testing the "jcmd <classname>"
functionality. A better fix (but not worth it IMHO) would be to spawn a
separate test process rather than using the main test process, which is
always going to share the main class name with other concurrently
running tests.
My concern with the fix is how long it will take to run these tests
sequentially, as they are run in tier2 and as part of the CI test job?
They are quick tests and there are only 3 of them. They appear to take
less than 5 seconds each.
Chris
Thanks,
David
Bug: https://bugs.openjdk.java.net/browse/JDK-8166642
Webrev: http://cr.openjdk.java.net/~dtitov/8166642/webrev.01
The tests ran successfully with Mach5.
Best regards,
Daniil
