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'
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()
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
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
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
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 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
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: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
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 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 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
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 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
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
Thanks for the review. Yes - main difference is the java.security files.
The minor edits suggested in your first review are also done.
regards,
Sean.
On 14/09/2017 22:12, Bradford Wetmore wrote:
The java.security files are the only differences? Then looks good to me.
Brad
On 9/14/2017 2:0
16 matches
Mail list logo