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
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 i
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
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 and
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:
> >
> >https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocketFactory.html#createSocket-java.net.Socket-java.io.InputS
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. Ap
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:
https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocketFactory.html#createSocket-java.n
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 (s
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
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:
> >>>
> >>>https://docs.oracle.co
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 close()
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. Applic
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 h
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 15/09/17
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 it'
16 matches
Mail list logo
