RFR: 8143121: javax/management/remote/mandatory/loading/MethodResultTest.java fails intermittently
Daniel Fuchs
daniel.fuchs at oracle.com
Tue Nov 24 14:22:08 UTC 2015
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 ;-)
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