Hi,
Please find below a trivial fix for:
8249812: java/net/DatagramSocket/PortUnreachable.java still fails
intermittently with SocketTimeoutException
https://bugs.openjdk.java.net/browse/JDK-8249812
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8249812/webrev.00/
The main method h
On 22/07/2020 12:28, Daniel Fuchs wrote:
Hi,
Please find below a trivial fix for:
8249812: java/net/DatagramSocket/PortUnreachable.java still fails
intermittently with SocketTimeoutException
https://bugs.openjdk.java.net/browse/JDK-8249812
webrev:
http://cr.openjdk.java.net/~dfuchs
Hi Alan,
On 22/07/2020 12:40, Alan Bateman wrote:
Would it be simpler to just remove the try/catch? Also in the main
method, put a trace message when it catches BindException so that the
.jtr will record why it retries.
Good points:
http://cr.openjdk.java.net/~dfuchs/webrev_8249812/webrev.01
On 22/07/2020 13:04, Daniel Fuchs wrote:
Hi Alan,
On 22/07/2020 12:40, Alan Bateman wrote:
Would it be simpler to just remove the try/catch? Also in the main
method, put a trace message when it catches BindException so that the
.jtr will record why it retries.
Good points:
http://cr.open
Thanks again Alan. My apologies for the delayed response, I was away most of
yesterday.
I've updated the webrev with the change as requested:
http://cr.openjdk.java.net/~adityam/nikola/fast_connect_loopback_3/
None of us here at Microsoft have contributor status yet, so I'll need a
sponsor to
Hi,
I believe there was a subtle timing hole introduced into the
HttpURLConWithProxy.java test with the
fix for JDK-8183369 [1]. In our local tests, when using GC stress modes, we
consistently get a failure
reported as:
"Execution failed: `main' threw exception: java.lang.RuntimeException:
Con
Hi Nikola,
One note.
src\java.base\windows\native\libnet\net_util_md.h
IN6_IS_ADDR_V4MAPPED_LOOPBACK considers only 127.0.0.1 as loopback
address, but AFAIR it's the whole block 127.0.0.0/8 and 127.0.0.1 is
just the most common used address.
--alex
On 07/22/2020 07:14, Nikola Grcevski wrote
Hi Alex,
Yes, you are right about that. I didn't think about extending the check to more
than 127.0.0.1.
The existing macro was only testing for 127.0.0.1 in both IP4 and IP6 modes, so
if the consensus
is that we want to extend to all of the possible loopback addresses, I can
modify the macro
