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

Erik Gahlin erik.gahlin at oracle.com
Wed Jun 18 07:37:29 UTC 2014


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/20140618/6e536bc8/attachment.html>


More information about the serviceability-dev mailing list