[RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

[Rob McKenna]

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. 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