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

Xuelei Fan xuelei.fan at oracle.com
Fri Sep 15 14:57:00 UTC 2017

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

More information about the security-dev mailing list