Yes, very weird
Could have been that I needed the tools.jar in the child processes, or
it could have been something else. If I remember correctly, I got a CNF
that I didn't get with the shell script, but it was few months back.
Anyway, I retried with JPRT and now it works without the shell script.
http://cr.openjdk.java.net/~egahlin/8028474_2/
Erik
Staffan Larsen skrev 2014-06-16 13:49:
On 16 jun 2014, at 12:32, Erik Gahlin <erik.gah...@oracle.com
<mailto:erik.gah...@oracle.com>> wrote:
Yekaterina Kantserova skrev 13/06/14 12:59:
Erik,
is there some reason why we need to keep MonitorVmStartTerminate.sh?
I've moved the JTreg header to MonitorVmStartTerminate.java
Hi Katja,
That's how I did the test initially, and it works locally, but I
could never get it to work in JPRT without the shell script. I
believe the tools.jar is not on the class path.
That is weird. I see other tests that depend in tools.jar and they
work fine.
/Staffan
Erik
/*
* @test
* @bug 4990825
* @summary attach to external but local JVM processes
* @library /lib/testlibrary
* @build jdk.testlibrary.*
* @run main MonitorVmStartTerminate
*/
and the test works just fine.
The JTreg run contains all pathes and system properties
MonitorVmStartTerminate.sh tries to construct:
${JAVA} ${TESTVMOPTS} -Dtest.jdk=${TESTJAVA}
-Dtest.classes=${TESTCLASSES} -classpath ${CP} MonitorVmStartTerminate
See the log attached.
Note *@build jdk.testlibrary.** instead of *@build
jdk.testlibrary.ProcessTools* to make sure all testlibrary classes
are compiled
to the right place when running tests concurrently.
Thanks,
Katja (Not a Reviewer)
On 06/12/2014 12:37 AM, Erik Gahlin wrote:
Hi,
Could I have a review of a test that has been failing
intermittently. The test now uses files for synchronization
instead of waiting for a process that sleeps.
Webrev:
http://cr.openjdk.java.net/~egahlin/8028474/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8028474
Description:
The test starts ten Java processes, each with a unique id.
Each process creates a file named after the id and then it waits for
the test to remove the file, at which the Java process exits.
The processes are monitored by the test to make sure notifications
are sent when processes are started/terminated.
To avoid Java processes being left behind, in case of an unexpected
failure, shutdown hooks are registered that remove files when the
test
exits. If files are not removed, i.e. due to a JVM crash,
the Java processes will exit themselves after 1000 s.
Thanks
Erik