Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind
Hi Roger, The test has been updated. It now uses System.nanoTime. http://cr.openjdk.java.net/~egahlin/8028474_6/ Thanks Erik roger riggs skrev 2014-07-01 14:35: Hi Erik, Consider switching to System.nanoTime; it is not sensitive to clock changes and avoids leaving a land mine that may cause a spurious non-repeatable test failure. 'Deducing it from the log' means there is a failure and creates probably an hour or two of work for some quality engineer and burns a couple of hours re-running the test run. Roger On 7/1/2014 3:37 AM, Erik Gahlin wrote: JavaProcess.waitForRemoval: How about using timestamps (currentTimeMillis()) before the loop and for each ite ration to determine if the timeout has expired (instead of time+=100”)? The code now uses currentTimeMillis(). Premature timeouts due to clock changes can be deduced from the log.
Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind
Hi Erik, nice cleanup! L160 break statement after this line would save unnecessary iterating when a process has already been found L172 You could use return true. - 'MonitoredVmUtil.mainArgs(target).contains(args)' has been asserted to be true on L171 -JB- On 07/03/2014 01:06 PM, Erik Gahlin wrote: Hi Roger, The test has been updated. It now uses System.nanoTime. http://cr.openjdk.java.net/~egahlin/8028474_6/ Thanks Erik roger riggs skrev 2014-07-01 14:35: Hi Erik, Consider switching to System.nanoTime; it is not sensitive to clock changes and avoids leaving a land mine that may cause a spurious non-repeatable test failure. 'Deducing it from the log' means there is a failure and creates probably an hour or two of work for some quality engineer and burns a couple of hours re-running the test run. Roger On 7/1/2014 3:37 AM, Erik Gahlin wrote: JavaProcess.waitForRemoval: How about using timestamps (currentTimeMillis()) before the loop and for each ite ration to determine if the timeout has expired (instead of time+=100”)? The code now uses currentTimeMillis(). Premature timeouts due to clock changes can be deduced from the log.
Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind
On 07/03/2014 04:44 PM, Erik Gahlin wrote: Hi Jaroslav, Here is an updated webrev: http://cr.openjdk.java.net/~egahlin/8028474_7/ Thanks. No more comments. -JB- See comments inline. Jaroslav Bachorik skrev 2014-07-03 16:03: Hi Erik, nice cleanup! L160 break statement after this line would save unnecessary iterating when a process has already been found I'm not a big fan of break statements in nested loops, so refactored out a separate method that returns when the process has been found. Also updated releaseStarted L172 You could use return true. - 'MonitoredVmUtil.mainArgs(target).contains(args)' has been asserted to be true on L171 Ops, not sure how it got there. Thanks Erik -JB- On 07/03/2014 01:06 PM, Erik Gahlin wrote: Hi Roger, The test has been updated. It now uses System.nanoTime. http://cr.openjdk.java.net/~egahlin/8028474_6/ Thanks Erik roger riggs skrev 2014-07-01 14:35: Hi Erik, Consider switching to System.nanoTime; it is not sensitive to clock changes and avoids leaving a land mine that may cause a spurious non-repeatable test failure. 'Deducing it from the log' means there is a failure and creates probably an hour or two of work for some quality engineer and burns a couple of hours re-running the test run. Roger On 7/1/2014 3:37 AM, Erik Gahlin wrote: JavaProcess.waitForRemoval: How about using timestamps (currentTimeMillis()) before the loop and for each ite ration to determine if the timeout has expired (instead of time+=100”)? The code now uses currentTimeMillis(). Premature timeouts due to clock changes can be deduced from the log.
Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind
I’m still ok with this. /Staffan On 3 jul 2014, at 16:42, Jaroslav Bachorik jaroslav.bacho...@oracle.com wrote: On 07/03/2014 04:44 PM, Erik Gahlin wrote: Hi Jaroslav, Here is an updated webrev: http://cr.openjdk.java.net/~egahlin/8028474_7/ Thanks. No more comments. -JB- See comments inline. Jaroslav Bachorik skrev 2014-07-03 16:03: Hi Erik, nice cleanup! L160 break statement after this line would save unnecessary iterating when a process has already been found I'm not a big fan of break statements in nested loops, so refactored out a separate method that returns when the process has been found. Also updated releaseStarted L172 You could use return true. - 'MonitoredVmUtil.mainArgs(target).contains(args)' has been asserted to be true on L171 Ops, not sure how it got there. Thanks Erik -JB- On 07/03/2014 01:06 PM, Erik Gahlin wrote: Hi Roger, The test has been updated. It now uses System.nanoTime. http://cr.openjdk.java.net/~egahlin/8028474_6/ Thanks Erik roger riggs skrev 2014-07-01 14:35: Hi Erik, Consider switching to System.nanoTime; it is not sensitive to clock changes and avoids leaving a land mine that may cause a spurious non-repeatable test failure. 'Deducing it from the log' means there is a failure and creates probably an hour or two of work for some quality engineer and burns a couple of hours re-running the test run. Roger On 7/1/2014 3:37 AM, Erik Gahlin wrote: JavaProcess.waitForRemoval: How about using timestamps (currentTimeMillis()) before the loop and for each ite ration to determine if the timeout has expired (instead of time+=100”)? The code now uses currentTimeMillis(). Premature timeouts due to clock changes can be deduced from the log.
Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind
On 1/07/2014 10:35 PM, roger riggs wrote: Hi Erik, Consider switching to System.nanoTime; it is not sensitive to clock changes Not completely true unfortunately. The change to use CLOCK_MONOTONIC_RAW will make it true (OS bugs not withstanding). But I would suggest switching anyway. David and avoids leaving a land mine that may cause a spurious non-repeatable test failure. 'Deducing it from the log' means there is a failure and creates probably an hour or two of work for some quality engineer and burns a couple of hours re-running the test run. Roger On 7/1/2014 3:37 AM, Erik Gahlin wrote: JavaProcess.waitForRemoval: How about using timestamps (currentTimeMillis()) before the loop and for each ite ration to determine if the timeout has expired (instead of time+=100”)? The code now uses currentTimeMillis(). Premature timeouts due to clock changes can be deduced from the log.
Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind
Updated webrev:
http://cr.openjdk.java.net/~egahlin/8028474_5/
See comments inline.
Staffan Larsen skrev 2014-06-26 13:22:
Indentation around JavaProcess.getId() is weird.
Fixed
JavaProcess.getPid/setPid/pid do not appear to be used.
Fixed
JavaProcess.waitForRemoval: How about using timestamps
(currentTimeMillis()) before the loop and for each ite
ration to determine if the timeout has expired (instead of time+=100”)?
The code now uses currentTimeMillis(). Premature timeouts due to clock
changes can be deduced from the log.
I also cleaned up the log for releaseStarted/releaseTerminated
nit: missing empty line before line 139, method releaseStarted().
Fixed
Thanks
Erik
/Staffan
On 26 jun 2014, at 00:56, Erik Gahlin erik.gah...@oracle.com
mailto:erik.gah...@oracle.com wrote:
It didn't work.
There's no termination notification, if I use
Process#destroyForcibly(). I believe the hsperfdata file is left
behind so it will not be able to detect that the process has died.
Here is an updated version that renames some variable/methods.
http://cr.openjdk.java.net/~egahlin/8028474_3/
Thanks
Erik
Erik Gahlin skrev 2014-06-18 09:37:
Didn't know about destroyForcibly(). I could try that.
Erik
Staffan Larsen skrev 18/06/14 09:26:
Erik,
How about using Process.destroyForcibly() as a means to terminate
the process instead of using files for signaling?
/Staffan
On 17 jun 2014, at 23:13, Erik Gahlin erik.gah...@oracle.com
mailto:erik.gah...@oracle.com wrote:
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
Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind
Looks good!
Thanks,
/Staffan
On 1 jul 2014, at 09:37, Erik Gahlin erik.gah...@oracle.com wrote:
Updated webrev:
http://cr.openjdk.java.net/~egahlin/8028474_5/
See comments inline.
Staffan Larsen skrev 2014-06-26 13:22:
Indentation around JavaProcess.getId() is weird.
Fixed
JavaProcess.getPid/setPid/pid do not appear to be used.
Fixed
JavaProcess.waitForRemoval: How about using timestamps (currentTimeMillis())
before the loop and for each ite
ration to determine if the timeout has expired (instead of time+=100”)?
The code now uses currentTimeMillis(). Premature timeouts due to clock
changes can be deduced from the log.
I also cleaned up the log for releaseStarted/releaseTerminated
nit: missing empty line before line 139, method releaseStarted().
Fixed
Thanks
Erik
/Staffan
On 26 jun 2014, at 00:56, Erik Gahlin erik.gah...@oracle.com wrote:
It didn't work.
There's no termination notification, if I use Process#destroyForcibly(). I
believe the hsperfdata file is left behind so it will not be able to detect
that the process has died.
Here is an updated version that renames some variable/methods.
http://cr.openjdk.java.net/~egahlin/8028474_3/
Thanks
Erik
Erik Gahlin skrev 2014-06-18 09:37:
Didn't know about destroyForcibly(). I could try that.
Erik
Staffan Larsen skrev 18/06/14 09:26:
Erik,
How about using Process.destroyForcibly() as a means to terminate the
process instead of using files for signaling?
/Staffan
On 17 jun 2014, at 23:13, Erik Gahlin erik.gah...@oracle.com wrote:
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 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
Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind
Hi Erik, Consider switching to System.nanoTime; it is not sensitive to clock changes and avoids leaving a land mine that may cause a spurious non-repeatable test failure. 'Deducing it from the log' means there is a failure and creates probably an hour or two of work for some quality engineer and burns a couple of hours re-running the test run. Roger On 7/1/2014 3:37 AM, Erik Gahlin wrote: JavaProcess.waitForRemoval: How about using timestamps (currentTimeMillis()) before the loop and for each ite ration to determine if the timeout has expired (instead of time+=100”)? The code now uses currentTimeMillis(). Premature timeouts due to clock changes can be deduced from the log.
Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind
Indentation around JavaProcess.getId() is weird.
JavaProcess.getPid/setPid/pid do not appear to be used.
JavaProcess.waitForRemoval: How about using timestamps (currentTimeMillis())
before the loop and for each iteration to determine if the timeout has expired
(instead of time+=100”)?
nit: missing empty line before line 139, method releaseStarted().
/Staffan
On 26 jun 2014, at 00:56, Erik Gahlin erik.gah...@oracle.com wrote:
It didn't work.
There's no termination notification, if I use Process#destroyForcibly(). I
believe the hsperfdata file is left behind so it will not be able to detect
that the process has died.
Here is an updated version that renames some variable/methods.
http://cr.openjdk.java.net/~egahlin/8028474_3/
Thanks
Erik
Erik Gahlin skrev 2014-06-18 09:37:
Didn't know about destroyForcibly(). I could try that.
Erik
Staffan Larsen skrev 18/06/14 09:26:
Erik,
How about using Process.destroyForcibly() as a means to terminate the
process instead of using files for signaling?
/Staffan
On 17 jun 2014, at 23:13, Erik Gahlin erik.gah...@oracle.com wrote:
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 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
Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind
Erik,
How about using Process.destroyForcibly() as a means to terminate the process
instead of using files for signaling?
/Staffan
On 17 jun 2014, at 23:13, Erik Gahlin erik.gah...@oracle.com wrote:
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 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
Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind
Didn't know about destroyForcibly(). I could try that.
Erik
Staffan Larsen skrev 18/06/14 09:26:
Erik,
How about using Process.destroyForcibly() as a means to terminate the
process instead of using files for signaling?
/Staffan
On 17 jun 2014, at 23:13, Erik Gahlin erik.gah...@oracle.com
mailto:erik.gah...@oracle.com wrote:
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
Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind
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
Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind
Hi Dmitry,
I'm not worried about files being left behind from a previous run , they
all have unique names.
Erik
Dmitry Samersoff skrev 2014-06-16 14:39:
Erik,
It's better to check lock-file age rather than maintain in-process
timeout variable, it guards the test from the situation when lock file
was not removed from the previous run for some reason.
see jdk/test/sun/management/jdp/JdpDoSomething.java
-Dmitry
On 2014-06-16 14:32, Erik Gahlin 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.
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
Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind
Erik,
It should work see e.g.
hotspot/test/runtime/RedefineFinalizer
you might need to add
-Xbootclasspath/a:tools.jar to @run
and
-XDignore.symbol.file to @compile
-Dmitry
On 2014-06-16 14:32, Erik Gahlin 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.
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
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
