RFR: 8293562: blocked threads with KeepAliveCache.get [v5]

[Daniel Jeliński]

On Thu, 29 Sep 2022 09:09:59 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Daniel Jeliński has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Describe oldClient
>
> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 442:
> 
>> 440:             // SSLSocket.close may block up to timeout. Make sure it's short.
>> 441:             serverSocket.setSoTimeout(1);
>> 442:         } catch (Exception e) {}
> 
> Is 1ms enough for a normal SSL close to complete? Does this mean that the normal close_notify exchange has to complete in that time?

full close takes one RTT, which may be much more than 1 ms. However, we are not aiming for a full close here; [TLS spec](https://datatracker.ietf.org/doc/html/rfc5246#section-7.2.1) says we don't have to wait for the peer's close_notify after sending ours, and we don't wait for it.
The wait is to make sure the OS sends our close_notify message, and does not send a RST packet during that time if we happen to receive data from the peer. 1ms is definitely sufficient for HTTP 1, where the server should only send data when requested.

-------------

PR: https://git.openjdk.org/jdk/pull/10401