Hi,
Please review, small code change below.
webrev: http://cr.openjdk.java.net/~vtewari/8185072/webrev0.0/index.html
BugId: https://bugs.openjdk.java.net/browse/JDK-8185072
this is regression because of "JDK-8179905".
Thanks,
Vyom
On 15/09/17 07:32, Xuelei Fan wrote:
> On 9/15/2017 7:16 AM, Rob McKenna wrote:
> >On 13/09/17 03:52, Xuelei Fan wrote:
> >>
> >>
> >>On 9/13/2017 8:52 AM, Rob McKenna wrote:
> >>>Hi Xuelei,
> >>>
> >>>This behaviour is already exposed via the autoclose boolean in:
> >>>
>
On 9/15/2017 7:16 AM, Rob McKenna wrote:
On 13/09/17 03:52, Xuelei Fan wrote:
On 9/13/2017 8:52 AM, Rob McKenna wrote:
Hi Xuelei,
This behaviour is already exposed via the autoclose boolean in:
When we call close() on the SSLSocket that calls close() on the
underlying java Socket which closes the native socket.
-Rob
On 13/09/17 04:09, Xuelei Fan wrote:
> It's a little bit complicated for layered SSL connections. Application can
> build a SSL connection on existing socket (we call
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
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 13/09/17 03:52, Xuelei Fan wrote:
>
>
> On 9/13/2017 8:52 AM, Rob McKenna wrote:
> >Hi Xuelei,
> >
> >This behaviour is already exposed via the autoclose boolean in:
> >
>
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.
Ah, right! This is the part I was missing.
So my fix is intended to address this specific circumstance only (where
we get caught in the while loop in waitForClose() indefinitely despite
having set a read timeout). In this situation it would be reasonable for
somebody to set a read timeout in the
This test calls close directly. (3rd last line in the stack)
I believe this is the only possible stack (with the new parameter) once
autoclose is set to false. If autoclose is true we'd skip the call to
waitForClose and just go directly to Socket.close() unless I'm mistaken.
-Rob
On
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.
On 15/09/17 07:07, Xuelei Fan wrote:
> On 9/15/2017 7:00 AM, Rob McKenna wrote:
> >When we call close() on the SSLSocket that calls close() on the
> >underlying java Socket which closes the native socket.
> >
> Sorry, I did not get the point. Please see the close() implementation of
> SSLSocket
On 9/15/2017 7:00 AM, Rob McKenna wrote:
When we call close() on the SSLSocket that calls close() on the
underlying java Socket which closes the native socket.
Sorry, I did not get the point. Please see the close() implementation
of SSLSocket (sun.security.ssl.SSLSocketImpl.close()) about the
On 9/15/2017 7:41 AM, Rob McKenna wrote:
On 15/09/17 07:07, Xuelei Fan wrote:
On 9/15/2017 7:00 AM, Rob McKenna wrote:
When we call close() on the SSLSocket that calls close() on the
underlying java Socket which closes the native socket.
Sorry, I did not get the point. Please see the
On 9/15/2017 8:22 AM, Rob McKenna wrote:
This test calls close directly. (3rd last line in the stack)
I believe this is the only possible stack (with the new parameter) once
autoclose is set to false. If autoclose is true we'd skip the call to
waitForClose and just go directly to Socket.close()
I still prefer to not-depends on socket receiving timeout. But I'm fine
if you want to move on with it.
As we can close the super socket in the current implementation, it
implies that application can handle it already. So you may not need the
system property and 5 times retries. I think
16 matches
Mail list logo
