Re: RFR: JDK-8184770: JDWP support for IPv6

2019-03-29 Thread Alex Menkov
tTransport.c fixed. --alex On 3/27/19, 7:04 PM, Alex Menkov wrote: Hi all, Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8184770 webrev: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.00/ Main changes are in socketTransport.c - the code is updated to support both IPv4 and

Re: RFR: JDK-8184770: JDWP support for IPv6

2019-04-01 Thread Alex Menkov
Hi Daniel, Chris, Unfortunately docs are out-dated (I plan to update it in JDK13). In JDK9 https://bugs.openjdk.java.net/browse/JDK-8041435 changed the behavior - empty address (i.e. only port is specified) means "local connections only", "*" means "all available connections". Then in JDK10 new

Re: RFR: JDK-8184770: JDWP support for IPv6

2019-04-01 Thread Alex Menkov
Hi Chris, On 04/01/2019 04:50, Chris Hegarty wrote: Alex, On 29/03/2019 22:07, Alex Menkov wrote: (added net-dev as suggested by Alan) Net gurus, please assist in reviewing socket-related code. New webrev: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/ Specifically on

Re: RFR: JDK-8184770: JDWP support for IPv6

2019-04-01 Thread Alex Menkov
On 04/01/2019 05:02, Chris Hegarty wrote: On 01/04/2019 12:50, Chris Hegarty wrote: ... Specifically on SocketTransportService.java. What Arthur has proposed is better ( changing to lastIndexOf alone is not sufficient ). Or is your assumption that the IPv6 literal is not enclosed in square b

Re: RFR: JDK-8184770: JDWP support for IPv6

2019-04-01 Thread Alex Menkov
Hi Daniel, As far as I see you are right. Attach to address with empty hostname will try to connect to "external" address instead of loopback. --alex On 04/01/2019 02:51, Daniel Fuchs wrote: Hi Arthur, Not directly related to Alex's original question but... On 30/03/2019 00:03, Arthur Euba

Re: RFR: JDK-8184770: JDWP support for IPv6

2019-04-02 Thread Alex Menkov
/startListening/startlis001.java (all other com/sun/jdi, nsk/jdi, nsk/jdwp, nsk/jdb test are passed). --alex On 04/01/2019 11:21, Alex Menkov wrote: Hi Chris, On 04/01/2019 04:50, Chris Hegarty wrote: Alex, On 29/03/2019 22:07, Alex Menkov wrote: (added net-dev as suggested by Alan) Net

Re: RFR: JDK-8184770: JDWP support for IPv6

2019-04-12 Thread Alex Menkov
veTest("NegativeMaskTest(" + test.localAddress + ")", test.allowAddress + "/" + test.prefixLengthBad);   A suggestion to move second argument to additional line: positiveTest("PositiveMaskTest(" + test.localAddress + ")", test.allowAddress + "/" + te

Re: RFR: JDK-8184770: JDWP support for IPv6

2019-04-23 Thread Alex Menkov
    if (name == NULL) { . . . . 1259 } while (0); 1260 if (jniEnv != NULL && (*jniEnv)->ExceptionCheck(jniEnv)) { Thanks! Serguei On 4/12/19 4:58 PM, Alex Menkov wrote: updated webrev: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.03/ changes (vs webrev.02) are non-function

Re: PING: Re: RFR: JDK-8184770: JDWP support for IPv6

2019-05-13 Thread Alex Menkov
Hi Chris, Serguei, Updated webrev: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.05/ CSR (approved): https://bugs.openjdk.java.net/browse/JDK-8223104 Changes (vs. webrev.04): - setsockopt(IPV6_V6ONLY) was moved from Win-specific code to shared setOptionsCommon function (in socketTransport.c)

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

2019-05-16 Thread Alex Menkov
On 05/16/2019 06:41, Ao Qi wrote: Hi Serguei, I saw your email [1], but I didn't receive it yet. Thanks for your review! I updated: http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/ Looks good. --alex On Thu, May 16, 2019 at 8:30 PM David Holmes wrote: What compiler was used here?

Re: RFR(s): Improving performance of Windows socket connect on the loopback adapter

2020-07-22 Thread Alex Menkov
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

RFR: 8224775: test/jdk/com/sun/jdi/JdwpListenTest.java failed to attach

2021-02-18 Thread Alex Menkov
The fix also partially fixes JdwpAttachTest failures (JDK-8253940). The failures are caused by network configuration changes during test execution ("global" IPv6 addresses disappears from interface). To minimize chances of intermittent failures like this java.net tests use only link-local address

Re: RFR: 8224775: test/jdk/com/sun/jdi/JdwpListenTest.java failed to attach

2021-02-18 Thread Alex Menkov
On Thu, 18 Feb 2021 21:43:00 GMT, Alex Menkov wrote: > The fix also partially fixes JdwpAttachTest failures (JDK-8253940). > The failures are caused by network configuration changes during test > execution ("global" IPv6 addresses disappears from interface). >

Re: RFR: 8224775: test/jdk/com/sun/jdi/JdwpListenTest.java failed to attach

2021-02-22 Thread Alex Menkov
On Mon, 22 Feb 2021 17:34:03 GMT, Daniel Fuchs wrote: > > > I don't see any specific issue with the proposed change but I don't know the > JDWP tests enough to provide more feedback than that. Do you have special > test cases for the IPv6 loopback? AFAIU this code here will filter it out? Go

Re: RFR: 8224775: test/jdk/com/sun/jdi/JdwpListenTest.java failed to attach [v2]

2021-02-22 Thread Alex Menkov
tests use > only link-local addresses whenever possible. > The fix does the same for JDI tests > (Utils.getAddressesWithSymbolicAndNumericScopes is used by JdwpListenTest > and JdwpAttachTest) Alex Menkov has updated the pull request incrementally with one additional commit since the

Integrated: 8224775: test/jdk/com/sun/jdi/JdwpListenTest.java failed to attach

2021-03-03 Thread Alex Menkov
On Thu, 18 Feb 2021 21:43:00 GMT, Alex Menkov wrote: > The fix also partially fixes JdwpAttachTest failures (JDK-8253940). > The failures are caused by network configuration changes during test > execution ("global" IPv6 addresses disappears from interface). >

Re: RFR: 8280010: Remove double buffering of InputStream for Properties.load

2022-01-14 Thread Alex Menkov
On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already > buffers input stream. Hence wrapping InputStream in BufferedInputStream is > redundant. Marked as reviewed by amenkov (Reviewer). - PR: https: