Re: HTTP client API
On 22 Sep 2016, at 00:14, Michael McMahon wrote: > > Martin > > The source is available in the JDK 9 sandbox (http-client-branch) at > http://hg.openjdk.java.net/jdk9/sandbox/ > > I think it has been updated to reflect the API as described below. Apologies, it has not been update yet. I will do it over the next day, or so, and post a note when it is done. -Chris. > Michael. > > On 21/09/2016, 14:14, Martin Buchholz wrote: >> >> >> On Wed, Sep 7, 2016 at 10:15 AM, Michael McMahon >> wrote: >> >> [1] http://cr.openjdk.java.net/~michaelm/httpclient/api.1/ >> >> [2] >> http://cr.openjdk.java.net/~michaelm/httpclient/specdiffout.1/package-summary.html >> >> Could we have actual source code for experimentation by interested parties?
Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses
it is good that you added the additional error code, "cover all bases", as they say. In any case your exception handling will inform if something has been missed, should it occur. So at the risk of triggering another MS curiosity, the changes look fine regards Mark On 21/09/2016 19:45, Rob McKenna wrote: The link would be handy: http://cr.openjdk.java.net/~robm/8159410/webrev.02/ -Rob On 21/09/16 07:44, Rob McKenna wrote: I've updated the webrev here with the copyright year (thanks Christoph) and extra error codes. I overlooked the codes from the old implementation of tcp_ping4 above this code. These are winsock error codes which I would expect IcmpSendEcho to use, but in our testing it actually returned the system error codes in at least one situation: https://msdn.microsoft.com/en-gb/library/windows/desktop/ms740668%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms681383%28v=vs.85%29.aspx -Rob On 21/09/16 06:32, Seán Coffey wrote: spotted an interesting blog on the MSDN timeout issue here : https://www.frameflow.com/ping-utility-flaw-in-windows-api-creating-false-timeouts/ Regards, Sean. On 21/09/16 17:42, Mark Sheppard wrote: the IcmpSendEcho series of calls come with some idiosyncrasies in that there is a minimum timeout that they can handle think it is about 1000msecs. isReachable can specify a finer grained timeout hence the need for timeout check regards Mark On 21/09/2016 17:18, Vyom Tewari wrote: Hi Rob, Do you really think this extra check is required ? if (pEchoReply->Status == IP_SUCCESS + && (int)pEchoReply->RoundTripTime <= timeout) I did not found any doc(MSDN) which explains this. I think in case of IP_SUCCESS "RoundTripTime" is always less than timeout. I think similar changes is required in Inet6Address.c as well ? Thanks, Vyom On Wednesday 21 September 2016 08:46 PM, Rob McKenna wrote: Hi folks, I'd like to fix a bug caused by an incorrect assumption. The IcmpSendEcho* calls can actually return a similar set of errors regardless of whether the call itself failed or succeeded. This change checks that both the call and the ping were successful. In addition to that it takes a number of common failure causes into account before deciding to throw an exception. http://cr.openjdk.java.net/~robm/8159410/webrev.01/ -Rob
Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses
> On 22 Sep 2016, at 18:04, Mark Sheppard wrote: > > > it is good that you added the additional error code, "cover all bases", as > they say. > In any case your exception handling will inform if something has been > missed, should it occur. > So at the risk of triggering another MS curiosity, the changes look fine +1 -Chris. > regards > Mark > > On 21/09/2016 19:45, Rob McKenna wrote: >> The link would be handy: >> >> http://cr.openjdk.java.net/~robm/8159410/webrev.02/ >> >> -Rob >> >> On 21/09/16 07:44, Rob McKenna wrote: >>> I've updated the webrev here with the copyright year (thanks Christoph) and >>> extra error codes. I overlooked the codes from the old implementation of >>> tcp_ping4 above this code. These are winsock error codes which I would >>> expect IcmpSendEcho to use, but in our testing it actually returned the >>> system error codes in at least one situation: >>> >>> https://msdn.microsoft.com/en-gb/library/windows/desktop/ms740668%28v=vs.85%29.aspx >>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms681383%28v=vs.85%29.aspx >>> >>> -Rob >>> >>> On 21/09/16 06:32, Seán Coffey wrote: spotted an interesting blog on the MSDN timeout issue here : https://www.frameflow.com/ping-utility-flaw-in-windows-api-creating-false-timeouts/ Regards, Sean. On 21/09/16 17:42, Mark Sheppard wrote: > the IcmpSendEcho series of calls come with some idiosyncrasies in that > there is a minimum timeout that they can handle > think it is about 1000msecs. isReachable can specify a finer grained > timeout hence the need for timeout check > > regards > Mark > > On 21/09/2016 17:18, Vyom Tewari wrote: >> Hi Rob, >> >> Do you really think this extra check is required ? >> >> if (pEchoReply->Status == IP_SUCCESS >> + && (int)pEchoReply->RoundTripTime <= timeout) I did not found any >> doc(MSDN) which explains this. I think in case of IP_SUCCESS >> "RoundTripTime" is always less than timeout. I think similar changes is >> required in Inet6Address.c as well ? Thanks, Vyom >> >> On Wednesday 21 September 2016 08:46 PM, Rob McKenna wrote: >>> Hi folks, >>> >>> I'd like to fix a bug caused by an incorrect assumption. The >>> IcmpSendEcho* calls can actually return a similar set of errors >>> regardless of whether the call itself failed or succeeded. This change >>> checks that both the call and the ping were successful. In addition to >>> that it takes a number of common failure causes into account before >>> deciding to throw an exception. >>> >>> http://cr.openjdk.java.net/~robm/8159410/webrev.01/ >>> >>> -Rob >
Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses
Thanks folks, I've been running some testing here and noticed that IP_REQ_TIMED_OUT can also be returned from IcmpSendEcho (as opposed to only being an error code in an ICMP_ECHO_REPLY) Updated webrev here: http://cr.openjdk.java.net/~robm/8159410/webrev.03/ -Rob On 22/09/16 06:12, Chris Hegarty wrote: > > > On 22 Sep 2016, at 18:04, Mark Sheppard wrote: > > > > > > it is good that you added the additional error code, "cover all bases", as > > they say. > > In any case your exception handling will inform if something has been > > missed, should it occur. > > So at the risk of triggering another MS curiosity, the changes look fine > > +1 > > -Chris. > > > regards > > Mark > > > > On 21/09/2016 19:45, Rob McKenna wrote: > >> The link would be handy: > >> > >> http://cr.openjdk.java.net/~robm/8159410/webrev.02/ > >> > >>-Rob > >> > >> On 21/09/16 07:44, Rob McKenna wrote: > >>> I've updated the webrev here with the copyright year (thanks Christoph) > >>> and extra error codes. I overlooked the codes from the old implementation > >>> of tcp_ping4 above this code. These are winsock error codes which I would > >>> expect IcmpSendEcho to use, but in our testing it actually returned the > >>> system error codes in at least one situation: > >>> > >>> https://msdn.microsoft.com/en-gb/library/windows/desktop/ms740668%28v=vs.85%29.aspx > >>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms681383%28v=vs.85%29.aspx > >>> > >>> -Rob > >>> > >>> On 21/09/16 06:32, Seán Coffey wrote: > spotted an interesting blog on the MSDN timeout issue here : > https://www.frameflow.com/ping-utility-flaw-in-windows-api-creating-false-timeouts/ > > Regards, > Sean. > > On 21/09/16 17:42, Mark Sheppard wrote: > > the IcmpSendEcho series of calls come with some idiosyncrasies in that > > there is a minimum timeout that they can handle > > think it is about 1000msecs. isReachable can specify a finer grained > > timeout hence the need for timeout check > > > > regards > > Mark > > > > On 21/09/2016 17:18, Vyom Tewari wrote: > >> Hi Rob, > >> > >> Do you really think this extra check is required ? > >> > >> if (pEchoReply->Status == IP_SUCCESS > >> + && (int)pEchoReply->RoundTripTime <= timeout) I did not found any > >> doc(MSDN) which explains this. I think in case of IP_SUCCESS > >> "RoundTripTime" is always less than timeout. I think similar changes is > >> required in Inet6Address.c as well ? Thanks, Vyom > >> > >> On Wednesday 21 September 2016 08:46 PM, Rob McKenna wrote: > >>> Hi folks, > >>> > >>> I'd like to fix a bug caused by an incorrect assumption. The > >>> IcmpSendEcho* calls can actually return a similar set of errors > >>> regardless of whether the call itself failed or succeeded. This > >>> change checks that both the call and the ping were successful. In > >>> addition to that it takes a number of common failure causes into > >>> account before deciding to throw an exception. > >>> > >>> http://cr.openjdk.java.net/~robm/8159410/webrev.01/ > >>> > >>> -Rob > > >
RFR(XS): 8166584: Remove obsolete utility function NET_ThrowSocketException in windows libnet
Hi, while looking at utility functions for creating exceptions in libjava/libnet I found a small spot that should be consolidated right away. The function NET_ThrowSocketException does only exist in the windows native implementation and is only used in 3 places in SocketInputStream.c. I removed this in favor of directly calling JNU_ThrowByName as the Unix variant of that code already does. In that function Java_java_net_SocketInputStream_socketRead0 I also replaced throwing a SocketException with throwing an NPE in the rare case that a the JNI input for the file descriptor is null. That's probably more natural and should virtually never occur anyways. Bug: https://bugs.openjdk.java.net/browse/JDK-8166584 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166584.0/ Thanks in advance for reviewing :) Best regards Christoph
