[teststabilization] RFR: 8225430: Replace wildcard address with loopback or local host in tests - part 14

Aleks Efimov aleksej.efimov at oracle.com
Wed Aug 7 16:09:55 UTC 2019


Hi Daniel,
Thank you for the review. The replies are in-lined below. The new 
version of the webrev can be found here:
http://cr.openjdk.java.net/~aefimov/8225430/01

With Best Regards,
Aleksei


On 06/08/2019 18:09, Daniel Fuchs wrote:
> Hi Aleksei,
>
> Thanks for taking care of these tests!
>
> http://cr.openjdk.java.net/~aefimov/8225430/00/test/jdk/java/net/Socket/NullHost.java 
>
>
>   39             svr.bind(new 
> InetSocketAddress(InetAddress.getLoopbackAddress(), 0));
>
>   maybe it would be worth adding a comment just before this line:
>
>   // The client side calls Socket((String) null, ...) which
>   // resolves to InetAddress.getByName((String)null) which in
>   // turns will resolve to the loopback address.
Thanks - comment added.

>
> HandleContentTypeWithAttrs.java:
>
>  Since the original test had a backlog of 50:
>  138         serverSocket = new ServerSocket(port, 50);
>  maybe we should preserve it, and uses the ServerSocket constructor
>  that takes a backlog number in the new code.
I've removed 50 value because the default value in ServerSocket is also 
50. I do not see this value documented in javadoc [1] and it could be 
changed in future, so let me return it back to the test code.
But I couldn't see how two-integers ServerSocket constructor can be used 
here since it will bind the socket address to 
InetAddress.anyLocalAddress():
     var ss = new ServerSocket(12345,50);
     ss.isBound() returns true
     ss.getLocalSocketAddress() returns 0.0.0.0/0.0.0.0:12345

Therefore I've added 50 backlog value to the ServerSocket::bind call

[1] 
https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/net/ServerSocket.html
>
> best regards,
>
> -- daniel
>
> PS: RedirectLimit.java
>
> One trick that's been used before - and that might be of interest
> here if this test is observed failing again, is to make the server
> side ignore any request that obviously don't come from the
> test itself. One way of doing that could be e.g to ignore
> (closing the accepted socket and doing as if nothing had been
> received) a request whose URI path doesn't match what the
> client is supposed to send, and possibly make that URI path
> sufficiently unique so that the test is the only one to use it.
>
> I'm not suggesting we should do this here, but something to keep
> in mind if tests are observed failing due to rogue connections
> from other processes on the machine.

Thanks I will keep that trick in mind and apply it if test fails again.

>
>
> On 06/08/2019 15:35, Aleks Efimov wrote:
>> Hi,
>>
>> Please help to review few test fixes which address intermittent 
>> networking failures:
>> http://cr.openjdk.java.net/~aefimov/8225430/00
>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8225430
>>
>> The following tests have been marked with @intermittent keyword:
>> java/net/DatagramSocket/ReuseAddressTest.java
>> java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java
>>
>> With Best Regards,
>> Aleksei
>



More information about the net-dev mailing list