RFR 8085049/9, java/net/MulticastSocket/TimeToLive.java fails intermittently with "Address already in use"

2016-09-23 Thread Felix Yang

Hi there,

please review a minor test fix to avoid hard-coded port usage, 
which leads to "Address already in use" issue intermittently.


Bug:

https://bugs.openjdk.java.net/browse/JDK-8085049

Since it is just a 1 line change, just print the patch here:

diff -r 83030d149c5c test/java/net/MulticastSocket/TimeToLive.java
--- a/test/java/net/MulticastSocket/TimeToLive.java Fri Sep 23 
01:08:24 2016 +
+++ b/test/java/net/MulticastSocket/TimeToLive.java Fri Sep 23 
01:39:24 2016 -0700

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -37,7 +37,7 @@
 static int[] bad_ttls = { -1, 256 };

 public static void main(String[] args) throws Exception {
-MulticastSocket socket = new MulticastSocket(6789);
+MulticastSocket socket = new MulticastSocket();
 int ttl = socket.getTimeToLive();
 System.out.println("default ttl: " + ttl);
 for (int i = 0; i < new_ttls.length; i++) {


Thanks,

Felix



Re: RFR 8085049/9, java/net/MulticastSocket/TimeToLive.java fails intermittently with "Address already in use"

2016-09-23 Thread Chris Hegarty

Looks good. Thanks Felix.

-Chris.

On 23/09/16 10:21, Felix Yang wrote:

Hi there,

please review a minor test fix to avoid hard-coded port usage, which
leads to "Address already in use" issue intermittently.

Bug:

https://bugs.openjdk.java.net/browse/JDK-8085049

Since it is just a 1 line change, just print the patch here:

diff -r 83030d149c5c test/java/net/MulticastSocket/TimeToLive.java
--- a/test/java/net/MulticastSocket/TimeToLive.java Fri Sep 23
01:08:24 2016 +
+++ b/test/java/net/MulticastSocket/TimeToLive.java Fri Sep 23
01:39:24 2016 -0700
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights
reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -37,7 +37,7 @@
 static int[] bad_ttls = { -1, 256 };

 public static void main(String[] args) throws Exception {
-MulticastSocket socket = new MulticastSocket(6789);
+MulticastSocket socket = new MulticastSocket();
 int ttl = socket.getTimeToLive();
 System.out.println("default ttl: " + ttl);
 for (int i = 0; i < new_ttls.length; i++) {


Thanks,

Felix



Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses

2016-09-23 Thread Chris Hegarty

On 22/09/16 19:22, Rob McKenna wrote:

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/


Thanks Rob. This latest version looks good to me.

-Chris.


-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






Re: HTTP client API

2016-09-23 Thread Chris Hegarty

On 22/09/16 08:54, Chris Hegarty wrote:

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.


Done.

This was a little rushed. Further implementation clean up will
be necessary.

-Chris.


-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?