Hi Daniel, Latest webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219585/03/webrev/
It's incorporating your changes wrt. to some timeouts and asserting the expected exit code. Instead of the ProcessThread changes, I'm using the sendMessage() approach. That API is already there. Unfortunately when running both SSL and plain sockets tests, it would randomly fail for me. Even if I choose different sets of ports for plain/ssl. So I've taken a different route of randomly selecting SSL or plain. Overall, this should give reasonable coverage for both (plain and SSL). This made test stability improve a lot on my Linux x86_64 machine. Ran for 100 iterations without failure. I'll run this through jdk/submit now. Could you run this through your test system too, please? Would you be OK with getting this patch pushed once we'd have positive results for both? Thanks, Severin On Fri, 2019-03-01 at 15:08 +0000, Daniel Fuchs wrote: > Hi Severin, > > On 28/02/2019 15:47, Severin Gehwolf wrote: > > Yes, thanks for looking at this Daniel. That was my determination as > > well. However, even if we do all of the above, and add a test config > > with /etc/hosts mapping a non-loopback address to "localhost" it would > > break other tests. E.g. this one: > > java/net/InetAddress/GetLocalHostWithSM.java > > > > So I'd have to explore whether your suggestion with > > InetAddress.getLocalHost() is viable. It seems promising. > > > > I'll keep you posted. > > Thanks for keeping the investigation going! > > For what it's worth this is what I have been experimenting with: > http://cr.openjdk.java.net/~dfuchs/experiment-8219585/experiment.00/ > > It's only a POC and obviously need more cleaning. > Maybe some of the arbitrary timeouts in the test could be scaled > in accordance to timeout-factor (I think there's an adjustTimeout(long) > function somewhere in the test libs that does that). > > I ran it 50 times in our test system - and it passed on all platforms, > so there's yet hope :-) > > hope this helps, > > -- daniel > >
