RFR: 8143121: javax/management/remote/mandatory/loading/MethodResultTest.java fails intermittently

Jaroslav Bachorik jaroslav.bachorik at oracle.com
Tue Nov 24 14:36:26 UTC 2015 

On 24.11.2015 15:22, Daniel Fuchs wrote:
> On 24/11/15 15:09, Alexander Kulyakhtin wrote:
>> Hi Daniel,
>>
>> Yes, I've tried running the tests many times but it hasn't yet failed
>> for me.
>> The failures are reported to occur only rarely, however, the cause of
>> the failures is clear according to the stack trace at the CR.
>> For me the test, on all platforms, passes, as before, from the 1st
>> attempt.
>>
>> I do not know what timeout value would be the best and did not see
>> anything wrong with the initially proposed 3 sec timeout. Most of the
>> time the timeout will not occur and when it occurs it, probably, makes
>> sense to wait for a longer rather than for a shorter time.
>>
>> Can there be an agreement on the timeout value (such as the proposed
>> 100 ms) so I can submit the changes with the agreed time value?
>
> Hi Alexander,
>
> I'm OK with both values (10 or 100) - my preference would go to
> 100 because I know that tests are sometimes run with fastdebug
> builds using -Xcomp and that usually slows down things quite a bit...
> But this is just a hunch - I have no proof that 100 is better than
> 10 ;-)

You could use Util.adjustTimeout(value) to try and compensate for 
fastdebug builds. They have the timeout factor increased.

-JB-

>
> best regards,
>
> -- daniel
>
>>
>> Best regards,
>> Alexander
>>
>> ----- Original Message -----
>> From: daniel.fuchs at oracle.com
>> To: alexander.kulyakhtin at oracle.com, martinrb at google.com
>> Cc: serviceability-dev at openjdk.java.net
>> Sent: Tuesday, November 24, 2015 4:57:04 PM GMT +03:00 Iraq
>> Subject: Re: RFR: 8143121:
>> javax/management/remote/mandatory/loading/MethodResultTest.java fails
>> intermittently
>>
>> Hi Alexander,
>>
>> That still look good to me - I would maybe go for 100ms rather
>> than 10ms. Have you tried to run the test in the same
>> conditions/platform where the test was observed failing?
>>
>> best regards,
>>
>> -- daniel
>>
>>
>> On 24/11/15 13:58, Alexander Kulyakhtin wrote:
>>> Hi,
>>>
>>> Following the finding from Martin, I have changed the delay before the
>>> retry to 10 ms
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~akulyakh/8143121_03/test/javax/management/remote/mandatory/loading/MethodResultTest.java.udiff.html
>>>
>>>
>>> Best regards,
>>> Alexander
>>>
>>> ----- Original Message -----
>>> From: martinrb at google.com
>>> To: alexander.kulyakhtin at oracle.com
>>> Cc: daniel.fuchs at oracle.com, serviceability-dev at openjdk.java.net
>>> Sent: Monday, November 23, 2015 9:15:20 PM GMT +03:00 Iraq
>>> Subject: Re: RFR: 8143121:
>>> javax/management/remote/mandatory/loading/MethodResultTest.java fails
>>> intermittently
>>>
>>> 3 seconds sounds like an awfully long time between retries.  I'd guess
>>> that 10ms would be sufficient most of the time for other threads to get
>>> around to doing something, and 100ms for other Java processes.
>>>
>>> On Mon, Nov 23, 2015 at 7:00 AM, Alexander Kulyakhtin
>>> <alexander.kulyakhtin at oracle.com
>>> <mailto:alexander.kulyakhtin at oracle.com>> wrote:
>>>
>>>      Hi Daniel,
>>>
>>>      Thank you very much for your feedback.
>>>
>>>      I have posted to the group an updated webrev introducing a 3 sec
>>>      sleep before the next retry.
>>>
>>>      Webrev:
>>>
>>> http://cr.openjdk.java.net/~akulyakh/8143121_02/test/javax/management/remote/mandatory/loading/MethodResultTest.java.udiff.html
>>>
>>>
>>>      Best regards,
>>>      Alexander
>>>
>>>      ----- Original Message -----
>>>      From: daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>
>>>      To: alexander.kulyakhtin at oracle.com
>>>      <mailto:alexander.kulyakhtin at oracle.com>
>>>      Cc: serviceability-dev at openjdk.java.net
>>>      <mailto:serviceability-dev at openjdk.java.net>
>>>      Sent: Monday, November 23, 2015 5:51:28 PM GMT +03:00 Iraq
>>>      Subject: Re: RFR: 8143121:
>>>      javax/management/remote/mandatory/loading/MethodResultTest.java
>>>      fails intermittently
>>>
>>>      Hi Alexander,
>>>
>>>      On 23/11/15 13:09, Alexander Kulyakhtin wrote:
>>>       > Hi Daniel,
>>>       >
>>>       > Thank you very much for the review.
>>>       >
>>>       > I presumed that in such case the jtreg will terminate the
>>> test by
>>>      timeout and so I wanted to avoid any specific delays and counters.
>>>       > If it's not safe to presume that, then I'm going to limit the
>>>      number of retries to 5 times introducing a delay of 3 seconds
>>>      between the reties, or I can use any other values if there are more
>>>      preferable values.
>>>
>>>      I agree that it's usually better to avoid to handcraft
>>>      arbitrary timeouts in tests. These have a habit of
>>>      coming back and bite you ;-(
>>>
>>>      If the reason for the connection failure is a race
>>>      condition where the server side is not ready yet, then
>>>      forcing the client side to sleep will hopefully
>>>      make some room for the server side to come up.
>>>
>>>      What I'm most concerned here is avoiding the busy loop,
>>>      as the busy loop could make things worse (rather than
>>>      helping).
>>>
>>>      So your proposed changes sound good - and Shanliang's
>>>      too - provided you free up some CPU time for the other
>>>      (possibly daemon) threads to complete their work.
>>>
>>>      best regards,
>>>
>>>      -- daniel
>>>
>>>       >
>>>       > Best regards,
>>>       > Alexander
>>>       >
>>>       >
>>>       >
>>>       >
>>>       > ----- Original Message -----
>>>       > From: daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>
>>>       > To: alexander.kulyakhtin at oracle.com
>>>      <mailto:alexander.kulyakhtin at oracle.com>,
>>>      serviceability-dev at openjdk.java.net
>>>      <mailto:serviceability-dev at openjdk.java.net>
>>>       > Sent: Monday, November 23, 2015 2:32:27 PM GMT +03:00 Iraq
>>>       > Subject: Re: RFR: 8143121:
>>>      javax/management/remote/mandatory/loading/MethodResultTest.java
>>>      fails intermittently
>>>       >
>>>       > Hi Alexander,
>>>       >
>>>       > This looks a bit dangerous to me - it could create a busy loop
>>>       > if for some reason the connection can never go through.
>>>       >
>>>       > I would suggest retrying only once (or retrying a fixed number
>>>       > of times) - and possibly introducing a small delay
>>> (Thread.sleep)
>>>       > before retrying.
>>>       >
>>>       > best regards,
>>>       >
>>>       > -- daniel
>>>       >
>>>       > On 23/11/15 12:19, Alexander Kulyakhtin wrote:
>>>       >> Hi,
>>>       >>
>>>       >> Could you, please, review this small, test-only, change:
>>>       >>
>>>       >> CR: https://bugs.openjdk.java.net/browse/JDK-8143121
>>>       >> Webrev:
>>>
>>> http://cr.openjdk.java.net/~akulyakh/8143121/test/javax/management/remote/mandatory/loading/MethodResultTest.java.udiff.html
>>>
>>>       >>
>>>       >> The precondition for this test is a JMXConnector having
>>>      established a successful connection.
>>>       >> On some environments the test sometimes can not connect at the
>>>      first attempt, because the target application is not yet ready.
>>>       >> We are changing the test so that it tries to connect again
>>> if it
>>>      gets IOException during the connection.
>>>       >>
>>>       >> Best regards,
>>>       >> Alexander
>>>       >>
>>>       >
>>>
>>>
>>
>

More information about the serviceability-dev mailing list