RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22

[David Holmes]

Hi Amit,

On 23/02/2017 4:18 PM, Amit Sapre wrote:
> Hello,
>
> Thanks David & Harsha for your inputs.
> Here is the new webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.01/

You didn't leave L116 - L121 as-is, you deleted them. Isn't checking 
they are all 0 a useful sanity check?

Moving the printing into listenersAreAll is not ideal as the only way to 
control the output rate is by changing the sleep time in the loop. But 
we want the test to be responsive (no big sleeps) and also don't want 
excessive output. The 500ms sleep might be a reasonable compromise but I 
can't tell that - how long does the test normally take to run and how 
much output is generated?

Thanks,
David

> Thanks,
> Amit
>
>> -----Original Message-----
>> From: David Holmes
>> Sent: Thursday, February 23, 2017 9:24 AM
>> To: serviceability-dev at openjdk.java.net; Sapre Amit
>> Cc: Harsha Wardhana B
>> Subject: Re: RFR : JDK-7132577 -
>> javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22
>>
>> Hi Amit,
>>
>> On 23/02/2017 12:18 AM, Harsha Wardhana B wrote:
>>> Hi Amit,
>>>
>>> There is no need to wait in a loop to check we have not received any
>>> notifications. Without starting the monitors, the listener count will
>>> be zero.
>>>
>>> The first part of diff L116-L121 could be left as is.
>>
>> Agreed.
>>
>>> By relying on Jtreg timeout for receiving notifications, we will be
>>> unable to print the number of listeners emitted by each Monitor. But
>> I
>>> guess there is no way to intercept a Jtreg timeout and print out
>> those
>>> values.
>>
>> You could print out the values every 1 second, or 5 or 10, ... at least
>> that way we can see what the values are when we timeout, and also if
>> they have been changing.
>>
>> Thanks,
>> David
>>
>>> Regards
>>>
>>> Harsha
>>>
>>>
>>> On Wednesday 22 February 2017 03:29 PM, Amit Sapre wrote:
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> Please review this test bug fix which eliminates test case's own
>>>> timeout mechanism to default jtreg timeout.
>>>>
>>>>
>>>>
>>>> Bug ID : https://bugs.openjdk.java.net/browse/JDK-7132577
>>>>
>>>> Webrev :
>>>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-
>> 7132577/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Easapre/webrev/2017/JDK-
>> 7132577/webrev.
>>>> 00/>
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Amit
>>>>
>>>