[RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

Xuelei Fan xuelei.fan at oracle.com
Fri Sep 15 14:23:12 UTC 2017


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