RFR: 8219585: [TESTBUG] sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java passes trivially when it shouldn't

[Daniel Fuchs]

Hi Severin,

On 08/03/2019 13:20, Severin Gehwolf wrote:
> On Fri, 2019-03-08 at 11:59 +0000, Daniel Fuchs wrote:
>> - please verify on your local box if testing both plain &
>>     SSL with a Thread.sleep(1000) in between makes the test
>>     more stable. If it does, then I'd prefer we go down
>>     this road rather than selecting one plain vs SSL at random.
> 
> I've tested this before. With a sleep of 1 or 2 seconds. It didn't work
> reliably for me (it might have been a fastdebug JVM).

fastdebug VM (sigh!) - that's a config I hadn't tested.
see below...

> Eventually, the
> SSL version of the test would fail. Yet, the latest version of the
> webrev used different sets of ports for SSL and plain so that led me to
> believe it's not related to a port clash. So Thread.sleep() wouldn't
> help. 

Good point.

> Have you tried without the sleep at all and running both plain
> and SSL in your test system?

Yes. As in your webrev.04 below - Works fine with regular VM.

> This is what I have tried:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219585/04/webrev/
> 
> If you think we should try this one. That's fine with me.

I have now also tested webrev.04 with a test config that uses
the fastdebug VM and observed many intermittent failures.
The logs let me think that maybe the JMX agent needed to be
given more time to come up:

So I am now experimenting with your webrev.04 above - but with the
following additional change to JMXAgentInterfaceBinding.java:

         private static final int WAIT_FOR_JMX_AGENT_TIMEOUT_MS = 20000;

So far the result are looking better, but tests are still running.
I wonder whether the same change would also reduce the number of
intermittent failures on your box?

best regards,

-- daniel

> 
> Thanks,
> Severin
>