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

[Erik Gahlin]

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.gahlin at oracle.com 
>> <mailto: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 
>>>> <mailto: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/20140626/41bd666a/attachment-0001.html>