[RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

[Xuelei Fan]

On 9/15/2017 7:44 AM, Rob McKenna wrote:
> Perhaps I'm misunderstanding you here. Can you illustrate this a bit
> further?
> 
The basic point is simple: removing the closing blocking even receiving 
timeout is not set.

> Applications already have to set a read timeout
I did not get the point.  Applications don't have to set a read timeout.

Xuelei

>, my proposal doesn't
> alter this fact. (i.e. if the read timeout isn't set applications which
> call close could potentially get stuck in readReply indefinitely)
> 
>      -Rob
> 
> On 15/09/17 07:23, Xuelei Fan wrote:
>> On 9/15/2017 7:07 AM, Rob McKenna wrote:
>>> But they are inextricably linked regardless.
>>>
>>> When we close an SSLSocket it performs a readReply which is subject to
>>> the read timeout. So if no read timeout is specified, the call to
>>> readReply will hang indefinitely.
>> That's one of what I worried about.  Applications have to set receiving
>> timeout in your proposal.  I don't want closing timeout binding to receiving
>> timeout.  It's doable and the impact is minimal.
>>
>> Xuelei
>>
>>> If a read timeout is specified we
>>> would need to maintain two separate timeouts and take each into account
>>> when polling.
>>>
>>> What you are suggesting would effectively necessitate a reimplementation
>>> of the close mechanics discarding the read timeout completely. (which
>>> would be a significant enough change in terms of compatibility)
>>>
>>>      -Rob
>>>
>>> On 13/09/17 03:56, Xuelei Fan wrote:
>>>> On 9/13/2017 8:52 AM, Rob McKenna wrote:
>>>>> W.r.t. a separate timeout, the underlying mechanics of a close already
>>>>> depend on the readTimeout in this situation.
>>>> That's a concerns of mine.  In order to work for your countermeasure,
>>>> applications have to set receiving timeout, and take care of the closing
>>>> timeout when evaluate what's a right timeout value.  The mixing could be
>>>> misleading and not easy to use.
>>>>
>>>> Xuelei