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

[Harsha Wardhana B]

Looks good.

-Harsha


On Thursday 23 February 2017 12:28 PM, Amit Sapre wrote:

Hello,

http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.02/ has the 
updated changes.

I ran this test on my VM and roughly takes 250-300 ms to get all the listener 
count.

Thanks,
Amit


-Original Message-
From: Amit Sapre
Sent: Thursday, February 23, 2017 11:55 AM
To: David Holmes; serviceability-dev@openjdk.java.net; Harsha Wardhana
B
Subject: RE: RFR : JDK-7132577 -
javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22

Hello,

In a messy run of this test case,
the number of prints for the counter values will be 240 (120 seconds is
jtreg timeout)

Will try to optimize this. Please hold on for a new webrev.

Thanks,
Amit



-Original Message-
From: Amit Sapre
Sent: Thursday, February 23, 2017 11:48 AM
To: David Holmes; serviceability-dev@openjdk.java.net; Harsha

Wardhana

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

Hello,

Thanks David & Harsha for your inputs.
Here is the new webrev :
http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.01/

Thanks,
Amit


-Original Message-
From: David Holmes
Sent: Thursday, February 23, 2017 9:24 AM
To: serviceability-dev@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

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

[David Holmes]

Hi Amit,

Just a couple of style nits:

! iterations++;
!
! if (10 == iterations) {

=>

  if (++iterations == 10) {
--

!iterations=0;

=>
 iterations = 0;

Thanks,
David

On 23/02/2017 4:58 PM, Amit Sapre wrote:

Hello,

http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.02/ has the 
updated changes.

I ran this test on my VM and roughly takes 250-300 ms to get all the listener 
count.

Thanks,
Amit


-Original Message-
From: Amit Sapre
Sent: Thursday, February 23, 2017 11:55 AM
To: David Holmes; serviceability-dev@openjdk.java.net; Harsha Wardhana
B
Subject: RE: RFR : JDK-7132577 -
javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22

Hello,

In a messy run of this test case,
the number of prints for the counter values will be 240 (120 seconds is
jtreg timeout)

Will try to optimize this. Please hold on for a new webrev.

Thanks,
Amit



-Original Message-
From: Amit Sapre
Sent: Thursday, February 23, 2017 11:48 AM
To: David Holmes; serviceability-dev@openjdk.java.net; Harsha

Wardhana

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

Hello,

Thanks David & Harsha for your inputs.
Here is the new webrev :
http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.01/

Thanks,
Amit


-Original Message-
From: David Holmes
Sent: Thursday, February 23, 2017 9:24 AM
To: serviceability-dev@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

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

[Amit Sapre]

Hello,

http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.02/ has the 
updated changes.

I ran this test on my VM and roughly takes 250-300 ms to get all the listener 
count.

Thanks,
Amit

> -Original Message-
> From: Amit Sapre
> Sent: Thursday, February 23, 2017 11:55 AM
> To: David Holmes; serviceability-dev@openjdk.java.net; Harsha Wardhana
> B
> Subject: RE: RFR : JDK-7132577 -
> javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22
> 
> Hello,
> 
> In a messy run of this test case,
> the number of prints for the counter values will be 240 (120 seconds is
> jtreg timeout)
> 
> Will try to optimize this. Please hold on for a new webrev.
> 
> Thanks,
> Amit
> 
> 
> > -Original Message-
> > From: Amit Sapre
> > Sent: Thursday, February 23, 2017 11:48 AM
> > To: David Holmes; serviceability-dev@openjdk.java.net; Harsha
> Wardhana
> > B
> > Subject: RE: RFR : JDK-7132577 -
> > javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22
> >
> > Hello,
> >
> > Thanks David & Harsha for your inputs.
> > Here is the new webrev :
> > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.01/
> >
> > Thanks,
> > Amit
> >
> > > -Original Message-
> > > From: David Holmes
> > > Sent: Thursday, February 23, 2017 9:24 AM
> > > To: serviceability-dev@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
> > > >>
> > > >

Re: 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@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

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

[Amit Sapre]

Hello,

Thanks David & Harsha for your inputs.
Here is the new webrev : 
http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.01/

Thanks,
Amit

> -Original Message-
> From: David Holmes
> Sent: Thursday, February 23, 2017 9:24 AM
> To: serviceability-dev@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
> >>
> >

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

[David Holmes]

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/




Thanks,

Amit

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

[Harsha Wardhana B]

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.

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.


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/ 



Thanks,

Amit

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

[Erik Gahlin]

Looks good.

Erik


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/ 



Thanks,

Amit

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

[Amit Sapre]

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/ 

 

Thanks,

Amit