[RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

[Xuelei Fan]

On 9/13/2017 5:52 AM, Xuelei Fan wrote:
> 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.
> 
typo and missed, "not granted to be closed 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
>>