[11] RFR: 8208496: New Test to verify concurrent behavior for TLS.

Sibabrata Sahoo sibabrata.sahoo at oracle.com
Fri Aug 3 17:50:56 UTC 2018


serverSocket.close() and serverSocket.accept() are not declared synchronized in java/net/ServerSocket.java.

Thanks,
Siba

-----Original Message-----
From: Xuelei Fan 
Sent: Friday, August 03, 2018 10:38 PM
To: Sibabrata Sahoo <sibabrata.sahoo at oracle.com>; John Jiang <sha.jiang at oracle.com>
Cc: security-dev at openjdk.java.net
Subject: Re: [11] RFR: 8208496: New Test to verify concurrent behavior for TLS.

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.sahoo at oracle.com>
> *Cc:* Xue-Lei Fan <xuelei.fan at oracle.com>; 
> security-dev at 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
> 



More information about the security-dev mailing list