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
