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

Alexander Kulyakhtin alexander.kulyakhtin at oracle.com
Thu Nov 26 11:59:25 UTC 2015


Hi, 

Following the comments from Daniel, Jaroslav and Olivier I've changed the delay to 100 ms making it adjustable using the Utils.adjustTimeout() method. 

Webrev: http://cr.openjdk.java.net/~akulyakh/8143121_04/test/javax/management/remote/mandatory/loading/MethodResultTest.java.udiff.html 

Best regards, 
Alexander 

----- Original Message ----- 
From: olivier.lagneau at oracle.com 
To: shanliang.jiang at oracle.com, daniel.fuchs at oracle.com 
Cc: serviceability-dev at openjdk.java.net 
Sent: Thursday, November 26, 2015 6:50:10 AM GMT +03:00 Iraq 
Subject: Re: RFR: 8143121: javax/management/remote/mandatory/loading/MethodResultTest.java fails intermittently 



+1 for retrying several times and sleeping between retries. testlibrary.Utils.waitForCondition() is a good candidate for such things. 

best regards, 
Olivier 

Le 23/11/2015 13:05, Shanliang JIANG a écrit : 


We could repeat retrying until the test harness timeout, but add a sleep is definitively useful between retrying.

Shanliang 

On 23 Nov 2015, at 12:32, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20151126/ab72f914/attachment.html>


More information about the serviceability-dev mailing list