[9] RFR: 8162484: javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails intermittently with "Address already in use" error

[Jamil Nimeh]

Hi Artem,

I'm not an official reviewer but the solution for making the servers 
reject connections rather than stop and start looks pretty fair to me 
and seems like a nice way to simulate a downed OCSP responder instead of 
having to bounce it.  A couple comments/questions:

I'm a bit surprised that you get the "Address already in use" error 
though.  Isn't servSocket.setReuseAddress(true) on line 214 supposed to 
set the SO_REUSEADDR at the system call level and prevent EADDRINUSE 
when listening or binding?

When you create the new ServerSocket on line 212, you're now binding it 
to the port now where originally it started as an unbound socket.  By 
doing so, the behavior of setReuseAddress() on line 214 is now 
undefined.  While this test no longer stops/starts the server, other 
tests may wish to do so and their behavior may not be consistent (though 
apparently it wasn't consistent even in the old scheme where the socket 
was unbound, then setReuseAddress() was called...)

--Jamil


On 08/10/2016 03:44 PM, Artem Smotrakov wrote:
> Hello,
>
> Please review this update for OCSP stapling tests.
>
> The tests use test/java/security/testlibrary/SimpleOCSPServer.java 
> which try to re-use a server port if the server restarted. Looks like 
> sometimes it may cause "Address already in use" error.
>
> The patch updates OCSP stapling tests with the following:
> - updated SSLSocketWithStapling.java test not to restart OCSP responders
> - updated SimpleOCSPServer to be able to reject incoming connections
> - updated SimpleOCSPServer to be able to reproduce a delay without 
> restarting
>
> Jamil,
>
> Could you please take a look at this update, and confirm if this 
> update doesn't break the original test scenarios?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8162484
> Webrev: http://cr.openjdk.java.net/~asmotrak/8162484/webrev.00/
>
> Artem