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.
Michael.
On 21/09/2016, 14:14, Martin Buchholz wrote:
On Wed, Sep 7, 2016 at 10:15 AM, Michael McMahon
mai
On Wed, Sep 7, 2016 at 10:15 AM, Michael McMahon <
michael.x.mcma...@oracle.com> 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 experimentati
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 a
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 syst
Yup. To elabourate:
If we set a small timeout for a faraway host with a high ping, IcmpSendEcho can
report success even if the rtt exceeded the timeout, hence the need for this
explicit check.
-Rob
On 21/09/16 11:07, Vyom Tewari wrote:
> So InetAddress.isReachable() will return false i
So InetAddress.isReachable() will return false if the underline API
IcmpSendEcho return with Status== IP_SUCESS and RoundTripTime > timeout.
Vyom
On Wednesday 21 September 2016 10:39 PM, Rob McKenna wrote:
Unfortunately the behaviour described is undocumented and was found the hard
way. This
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 tim
Unfortunately the behaviour described is undocumented and was found the hard
way. This part of the code is a necessity though.
-Rob
On 21/09/16 09:48, Vyom Tewari wrote:
> Hi Rob,
>
> Do you really think this extra check is required ?
>
> if (pEchoReply->Status == IP_SUCCESS
> + && (in
It's absolutely worth looking into and I'll get going on that, but I'd rather
deal with it separately to the ipv4 stuff. IcmpSendEcho already appears to
behave somewhat strangely, so I wouldn't necessarily assume that the ipv4 and
ipv6 code will end up being identical.
-Rob
On 21/09/16
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,
Hi Rob,
this looks good ...
do you think there is any need to replicate these changes in
Inet6AddressImpl.c ? (or leave it alone and don't trouble trouble
until trouble troubles you :-)
regards
Mark
regards
Mark
On 21/09/2016 16:16, Rob McKenna wrote:
Hi folks,
I'd like to fix a b
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
Hi Rob,
this looks like a nice fix and I can't see anything besides the copyright year
which you will for sure update when submitting. :)
Unfortunately I'm not a reviewer so you'll have to get another real review.
Best regards
Christoph
> -Original Message-
> From: net-dev [mailto:net-
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 nu
Felix,
On 21/09/16 03:31, Felix Yang wrote:
Hi Chris,
On 2016/9/20 23:22, Chris Hegarty wrote:
Felix,
On 20 Sep 2016, at 13:57, Felix Yang wrote:
Hi all,
please review the following test fix. It explicitly disables
proxy to make sure the test not affected by different environment
con
15 matches
Mail list logo
