[RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

[Xuelei Fan]

In theory, there are intermittent compatibility problems as this update 
may not close the SSL connection over the existing socket layer 
gracefully, even for high speed networking environments, while the 
underlying socket is alive.  The impact could be serious in some 
environment.

For safe, I may suggest turn this countermeasure off by default.  And 
providing options to turn on this countermeasure:
1. Close the SSL connection gracefully by default; or
2. Close the SSL connection after a timeout.

It's hardly to say 5 times receiving timeout is better/safer than 
timeout once in this context.  As you have already had a system property 
to control, you may be able to use options other than the customized 
socket receiving timeout, so that the closing timeout is not 
mixed/confused/dependent on/with the receiving timeout.

Put all together:
1. define a closing timeout, for example "jdk.tls.waitForClose".
2. the property default value is zero, no behavior changes.
3. applications can set positive milliseconds value for the property. 
The SSL connection will be closed in the set milliseconds (or about the 
maximum value between SO_TIMEOUT and closing timeout), the connection is 
not grant to be gracefully.

What do you think?

BTW, please file a CSR as this update is introducing an external system 
property.

Thanks,
Xuelei

On 9/11/2017 3:29 PM, Rob McKenna wrote:
> Hi folks,
> 
> In high latency environments a client SSLSocket with autoClose set to false
> can hang indefinitely if it does not correctly recieve a close_notify
> from the server.
> 
> In order to rectify this situation I would like to suggest that we
> implement an integer JDK property (jdk.tls.closeRetries) which instructs
> waitForClose to attempt the close no more times than the value of the
> property. I would also suggest that 5 is a reasonable default.
> 
> Note: each attempt times out based on the value of
> Socket.setSoTimeout(int timeout).
> 
> Also, the behaviour here is similar to that of waitForClose() when
> autoClose is set to true, less the retries.
> 
> http://cr.openjdk.java.net/~robm/8184328/webrev.01/
> 
>      -Rob
>