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

Erik Gahlin erik.gahlin at oracle.com
Tue Jun 17 21:20:50 UTC 2014


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
>



More information about the serviceability-dev mailing list