RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind

[Staffan Larsen]

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.gahlin at 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.gahlin at 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 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140618/fb4e1300/attachment-0001.html>