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

[Erik Gahlin]

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/20140617/692cabe9/attachment-0001.html>