[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    RR, M 7186723: TEST_BUG: Race condition in sun/management/jmxremote/startstop/JMXStartStopTest.sh
From:       Dmitry.Samersoff () oracle ! com (Dmitry Samersoff)
Date:       2012-08-29 10:34:09
Message-ID: 503DF021.1080109 () oracle ! com
[Download RAW message or body]

Alan,

Thank you for your help. Please see comments below in-line.

On 2012-08-26 10:27, Alan Bateman wrote:
> On 25/08/2012 21:16, Dmitry Samersoff wrote:
>> :
>> The test sends couple of jcmd commands to the single server process.
>> jcmd do attach, call, detach for each command. So I have to keep server
>> running for some time.
>>
>>  Server process with just while(true) sleep(1); would run forever if
>> test  doesn't kill it for some reason - it's why I use busy code.
>>
>> So I'm open for any advice here.
>>
>> -Dmitry
>>
> Our tests need to be very reliable and fast to be useful. With this one
> then I'm concerned that this busy code is going to hog a core on busy
> machines and just run too quickly on fast machines (although looking at
> the code I assume Quicksort(data,1000,0); will cause it to immediately
> barf so I don't think it actual runs).

Agree.

> 
> If I were writing this test then I would control the target process via
> a socket connection. That way you can instruct it to shutdown when
> required. You'll see an example in
> java/nio/channels/AsynchronousFileChannel/Lock.java. Closer to your home
> then com/sun/tools/attach/BasicTests.sh also uses the socket connection
> to shutdown the "application". 

I checked the tests above, socket trick save us from using PID and kill
on windows,

 but if nobody connects to the socket, - e.g. jtreg kills the test by
timeout, server application will run forever.

Also a port could be not available for some reason (e.g. McAfee) and we
would have hard to debug intermittent test failure.

so I use this idea but implemented it using tmp file.

Generally speaking, we should work with jtreg team to add a support for
client-server tests to the harness and get rid of all of these tricks.

> The other thing I would do is re-write as
> much as the test in java as possible, just to keep it portable and
> easier to maintain. I realize there is a slight complication here in
> that you need the pid but otherwise I don't see any reason to use a
> shell test.

I'm absolutely agree with you - we should avoid shell tests when possible.


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...



[prev in list] [next in list] [prev in thread] [next in thread]