Hi Siba,
The use of SO_TIMEOUT may cause intermittent failure in JDK test
environment. I'm not very sure if serverSocket.close() and
serverSocket.accept() are synchronized or not. If they did, there may
be a dead waiting condition.
Xuelei
On 8/3/2018 2:32 AM, Sibabrata Sahoo wrote:
Hi Xuelei/John,
I did a minor change to handle graceful shutdown of server thread along
with handling timeout for long waiting accept().
Webrev: http://cr.openjdk.java.net/~ssahoo/8208496/webrev.01/
<http://cr.openjdk.java.net/%7Essahoo/8208496/webrev.01/>
Thanks,
Siba
*From:*John Jiang
*Sent:* Friday, August 03, 2018 7:21 AM
*To:* Sibabrata Sahoo <sibabrata.sa...@oracle.com>
*Cc:* Xue-Lei Fan <xuelei....@oracle.com>; security-dev@openjdk.java.net
*Subject:* Re: [11] RFR: 8208496: New Test to verify concurrent behavior
for TLS.
Hi Siba,
Would it be better to check how many connections the server accepts?
In your case, the server must accept 50 (no more no less) connections;
otherwise, some problem may raise.
And I suppose, when the server thread is interrupted, the server socket
may not be closed.
The server should exit immediately and gracefully when it has accepted
all the connections.
If the server can be closed gracefully, it may be no need to set the
server thread as daemon.
Some minors:
-- 28 import java.net.SocketException;
This import statement looks unused.
-- 131 sslSocket.setNeedClientAuth(false);
Now that client auth is not requested by default, so it may be
unnecessary to set false value explicitly.
Best regards,
John Jiang
On 2018/8/2 18:41, Sibabrata Sahoo wrote:
Hi Xuelei,
Please review the patch for,
JBS: https://bugs.openjdk.java.net/browse/JDK-8208496
Webrev: http://cr.openjdk.java.net/~ssahoo/8208496/webrev.00/
<http://cr.openjdk.java.net/%7Essahoo/8208496/webrev.00/>
This is a new Test which test concurrent behavior of TLS. It uses 50
client thread to access a single server port concurrently and repeat
this process for each protocol supported.
Thanks,
Siba
