Hi Chris and Yasumasa,
Thank you for your comments!
I had faced connection leak on production by this handler. It seems
like a corner-case but it's a real risk to me.
I had focused REE on this issue, but it is a subclass of
RuntimeException, so I think that we should investigate
RuntimeException,
On 10/11/2016 20:26, Chris Hegarty wrote:
:
It has, but, for me at least, since the changes for 7120665 [1] require a
conformant implementation to support at least one network interface, it
seems more like an error if we encounter this situation.
Ugh, I'd forgotten that needs to be supported t
Same for that, as it goes together with 8167420.
From: Langer, Christoph
Sent: Mittwoch, 2. November 2016 15:37
To: 'net-dev@openjdk.java.net'
Subject: RFR(M): 8167457: Switch Windows Inet4AddressImpl to
getaddrinfo/getnameinfo
Hi,
here is the Windows counterpart of 8167420.
Bug: https://bugs
Hi,
I just wanted to ping on that one to make sure it does not get forgotten...
Best regards
Christoph
From: Langer, Christoph
Sent: Donnerstag, 3. November 2016 16:46
To: 'net-dev@openjdk.java.net'
Subject: RE: RFR(M): 8167420: remove redundant code path in
unix/native/libnet/Inet4AddressImpl
Hi,
> On 10 Nov 2016, at 16:48, Alan Bateman wrote:
> > On 10/11/2016 16:39, Mark Sheppard wrote:
> >> Hi,
> >> please oblige and review the change
> >>
> http://cr.openjdk.java.net/~msheppar/8164815/webrev/src/java.base/share/cl
> asses/java/net/NetworkInterface.java.sdiff.html
> >>
> >> to ad
On 10 Nov 2016, at 16:48, Alan Bateman wrote:
> On 10/11/2016 16:39, Mark Sheppard wrote:
>> Hi,
>> please oblige and review the change
>> http://cr.openjdk.java.net/~msheppar/8164815/webrev/src/java.base/share/classes/java/net/NetworkInterface.java.sdiff.html
>>
>>
>> to address the issue ra
On 10/11/2016 16:39, Mark Sheppard wrote:
Hi,
please oblige and review the change
http://cr.openjdk.java.net/~msheppar/8164815/webrev/src/java.base/share/classes/java/net/NetworkInterface.java.sdiff.html
to address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8164815
It w
> On 10 Nov 2016, at 14:43, Yasumasa Suenaga wrote:
>
> Hi,
>
>> I think it best to just handle the specific case of REE, as it done in
>> Yuji’s patch.
>
> Will it be a cause of connection leak if RuntimeException is occurred in
> handler method?
No, at least not from this point in the cod
Hi,
please oblige and review the change
http://cr.openjdk.java.net/~msheppar/8164815/webrev/src/java.base/share/classes/java/net/NetworkInterface.java.sdiff.html
to address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8164815
It was found during testing that, when a system doe
Hi,
Please find below a patch for:
https://bugs.openjdk.java.net/browse/JDK-8169495
8169495: Add a method to set an Authenticator on a HttpURLConnection.
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8169495/webrev.00
The public API changes are in java.net.HttpURLConnection and
java.net.Au
Hi,
I think it best to just handle the specific case of REE, as it done in Yuji’s
patch.
Will it be a cause of connection leak if RuntimeException is occurred in
handler method?
I think we should catch RuntimeException at least.
I think you can use finally statement to close the connectio
> On 9 Nov 2016, at 12:38, Yasumasa Suenaga wrote:
>
> Hi Yuji,
>
>> http://cr.openjdk.java.net/~ykubota/8169358/webrev.01/
I think Yuji’s patch is good as is.
> I think you can use finally statement to close the connection in this case.
I don’t believe that this is possible. The handling of
12 matches
Mail list logo
