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.fu...@oracle.com
To: alexander.kulyakh...@oracle.com, marti...@google.com
Cc: serviceability-dev@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: marti...@google.com
To: alexander.kulyakh...@oracle.com
Cc: daniel.fu...@oracle.com, serviceability-dev@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.kulyakh...@oracle.com
<mailto:alexander.kulyakh...@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.fu...@oracle.com <mailto:daniel.fu...@oracle.com>
To: alexander.kulyakh...@oracle.com
<mailto:alexander.kulyakh...@oracle.com>
Cc: serviceability-dev@openjdk.java.net
<mailto:serviceability-dev@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.fu...@oracle.com <mailto:daniel.fu...@oracle.com>
> To: alexander.kulyakh...@oracle.com
<mailto:alexander.kulyakh...@oracle.com>,
serviceability-dev@openjdk.java.net
<mailto:serviceability-dev@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
>>
>
