[RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

Rob McKenna rob.mckenna at oracle.com
Fri Sep 15 14:44:05 UTC 2017


Perhaps I'm misunderstanding you here. Can you illustrate this a bit
further?

Applications already have to set a read timeout, 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


More information about the security-dev mailing list