[RFR] 8184328: JDK8u131 socketRead0 hang at SSL read (original) (raw)

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