Re: RFR 8020758: HttpCookie constructor does not throw IAE when name contains a space

Hi Chris, yes, I concur, also regards Mark On 23/10/2013 12:09, Michael McMahon wrote: I agree. The change looks fine to me. Thanks Michael On 23/10/13 12:09, Chris Hegarty wrote: Mark, Michael, java.net.HttpCookie, rightly or wrongly, supports three different Cookie specifications. Some

hg: jdk8/tl/corba: 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB

Changeset: fe781b3badd6 Author:msheppar Date: 2013-11-21 11:30 + URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/fe781b3badd6 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB Summary: check for default ORBImpl and ORBSingleton set via pr

hg: jdk8/tl/jdk: 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB

Changeset: d5d4b9a63174 Author:msheppar Date: 2013-11-21 11:36 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5d4b9a63174 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB Summary: check for default ORBImpl and ORBSingleton set via prop

RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java

should have been this list by rights!! regards Mark Original Message Subject: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java Date: Fri, 29 Nov 2013 14:21:33 + From: Mark Sheppard Organization: Oracle Corporation To

Re: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java

n 11/29/13 5:19 PM, Alan Bateman wrote: On 29/11/2013 14:21, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025211/webrev/ which address the issue raised in the bug https://bugs.openjdk.java.net/browse/JDK-8025211 an intermittent fa

Re: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java

Hi based on feedback the changes for issue: https://bugs.openjdk.java.net/browse/JDK-8025211 have been amended to the following: http://cr.openjdk.java.net/~msheppar/8025211/webrev.02/ please oblige and review regards Mark On 29/11/2013 17:17, Mark Sheppard wrote: Alan, Daniel, thanks

hg: jdk8/tl/jdk: 8025211: Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java

Changeset: 39b3b0e77af5 Author:msheppar Date: 2013-12-02 14:01 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b3b0e77af5 8025211: Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java Summary: modified test to execute in a single thread to eliminate potent

RFR:JDK-7102702 - java/net/PortUnreachableException/OneExceptionOnly.java failing

Hi, please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/7102702/webrev/ to address the issue https://bugs.openjdk.java.net/browse/JDK-7102702 This test fails on windows, and it was found to be failing with an error WSAEFAULT (10014), when invoking a recvfro

Re: RFR:JDK-7102702 - java/net/PortUnreachableException/OneExceptionOnly.java failing

, and re-execute the regression suites. regards Mark On 18/12/2013 16:05, Chris Hegarty wrote: On 18 Dec 2013, at 15:13, Alan Bateman wrote: On 18/12/2013 15:09, Mark Sheppard wrote: Hi, please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/7102702/webrev

RFR: java/net/MulticastSocket/SetGetNetworkInterfaceTest.java throws java.net.SocketException: Cannot assign requested address

Hi, Please oblige and review the following changes: http://cr.openjdk.java.net/~msheppar/8027903/webrev/ which address the issue: https://bugs.openjdk.java.net/browse/JDK-8027903 The test failure was found to be due to an interface configured with an IPv6 address and no IPv4 address. The n

Re: RFR: java/net/MulticastSocket/SetGetNetworkInterfaceTest.java throws java.net.SocketException: Cannot assign requested address

:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:744) regards Mark On 29/12/2013 17:05, Alan Bateman wrote: On 23/12/2013 18:21, Mark Sheppard wrote: Hi, P

RFR: JDK-8015692 - java.net.BindException is thrown on Windows XP when HTTP server is started and stopped in the loop.

Hi Please oblige and review the changes in the webrev http://cr.openjdk.java.net/~msheppar/8015692/jdk9/webrev/ to address the issue raised in the bug https://bugs.openjdk.java.net/browse/JDK-8015692 Summary: a series Junit tests which start stop instances of an com.sun.net.httpserver.Ht

Re: RFR: JDK-8015692 - java.net.BindException is thrown on Windows XP when HTTP server is started and stopped in the loop.

hy you needed to add the selectNow() and the close() after you have joined the dispatcher thread? Since you are guaranteed that the dispatcher thread will have exited before join() returns? -Chris. On 17 Feb 2014, at 01:20, Mark Sheppard wrote: Hi Please oblige and review the changes

RFR: 8025293 - JNI exception pending checks in java.net

Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025293/webrev/ to address the issue in https://bugs.openjdk.java.net/browse/JDK-8025293 this applies additional checks after JNI native calls in src/solaris/native/java/net/NetworkInterface.c src/windows/

Re: RFR: 8025293 - JNI exception pending checks in java.net

fine. -Chris. On 4 Mar 2014, at 11:06, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025293/webrev/ to address the issue in https://bugs.openjdk.java.net/browse/JDK-8025293 this applies additional checks after JNI native calls i

Re: RFR: 8025293 - JNI exception pending checks in java.net

On 04/03/2014 11:06, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025293/webrev/ to address the issue in https://bugs.openjdk.java.net/browse/JDK-8025293 this applies additional checks after JNI native calls in src/solaris/nativ

RFR: JDK-8036607 - JNI exception pending in jdk/src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c

Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036607/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8036607 Summary: Changes to src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c two additions to take in

RFR: JDK8036601 - NI exception pending in jdk/src/windows/native/sun/net/dns/ResolverConfigurationImpl.c

Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036601/webrev/ which address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8036601 summary: NULL return value checks and JNU_ThrowOutOfMemoryError added regards Mark

Re: RFR: JDK8036601 - NI exception pending in jdk/src/windows/native/sun/net/dns/ResolverConfigurationImpl.c

Hi Alan, thanks for the reply yes, I'll add the STS_ERROR regards Mark On 12/03/2014 16:51, Alan Bateman wrote: On 12/03/2014 16:43, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036601/webrev/ This mostly looks go

RFR: JDK-8036600 - JNI exception pending in src/jdk/src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c

Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036600/webrev/ which address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8036600 summary: main changes are to check JNI return values, malloc returns and raise JNU_ThrowOutOfMemoryError

RFR: JDK-8035571 - Check jdk/src/windows/native/java/net/TwoStacksPlain* for JNI pending exceptions

Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8035571/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8035571 summary: JNI return value and pending exception checks added

RFR: JDK-8035631 - JNI exception pending in jdk/src/windows/native/java/net/NetworkInterface_winXP.c

Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8035631/webrev/ which address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8035631 Summary: added CHECK_NULL_RETURN after JNI calls regards Mark

Re: RFR: JDK-8035631 - JNI exception pending in jdk/src/windows/native/java/net/NetworkInterface_winXP.c

n L514. Is this intentional? L555. Not directly related to your changes, but should netaddrP be freed there before returning NULL? -Chris. On 14/03/14 19:04, Mark Sheppard wrote: Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8035631/webrev/ which add

RFR: 8044029 - JNI exception pending checks in java.net

Hi, please oblige and review the following fix http://cr.openjdk.java.net/~msheppar/8044029/webrev/ for the issue https://bugs.openjdk.java.net/browse/JDK-8044029 which is a backport of https://bugs.openjdk.java.net/browse/JDK-8025293 the changeset didn't appear to apply cleanly, necessitati

RFR: 8041609 - Check jdk/src/windows/native/java/io/WinNTFileSystem_md.c for JNI pending exceptions

Hi please oblige review and approve the backport to jdk8u-dev, after the review of the following change http://cr.openjdk.java.net/~msheppar/8041609/webrev/ for the issue https://bugs.openjdk.java.net/browse/JDK-8041609 which is a backport of https://bugs.openjdk.java.net/browse/JDK-80358

RFR: JDK-8040810 - Uninitialised memory in jdk/src/windows/native/java/net: net_util_md.c, TwoStacksPlainSocketImpl.c, TwoStacksPlainDatagramSocketImpl.c, DualStackPlainSocketImpl.c, DualStackPlainDa

Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8040810/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8040810 resulting from static code analysis. these changes explicitly initialize local function variables, whic

Re: RFR: JDK-8040810 - Uninitialised memory in jdk/src/windows/native/java/net: net_util_md.c, TwoStacksPlainSocketImpl.c, TwoStacksPlainDatagramSocketImpl.c, DualStackPlainSocketImpl.c, DualStackPla

HI Alan, thanks for the response ... yes, rv = 0 is isn't strictly necessary (in for a penny, in for a pound approach) regards Mark On 16/07/2014 18:28, Alan Bateman wrote: On 16/07/2014 18:00, Mark Sheppard wrote: Hi please oblige and review the following changes

RFR: JDK-8050922 - add additional diagnostic to java/net/MulticastSocket/TestInterfaces.java

Hi, please oblige and review the following diagnostic output addition to the test java/net/MulticastSocket/TestInterfaces.java http://cr.openjdk.java.net/~msheppar/8050922/webrev/ for the task https://bugs.openjdk.java.net/browse/JDK-8050922 which will assist in diagnosing an intermittent f

RFR: JDK-8054118 - java/net/ipv6tests/UdpTest.java failed intermittently

Hi, please oblige and review the following fix http://cr.openjdk.java.net/~msheppar/8054118/webrev/ to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8054118 The Windows test environment has a Teredo interface. This oscillates between being configured with IPv6 and not be

Re: RFR: JDK-8054118 - java/net/ipv6tests/UdpTest.java failed intermittently

thanks Chris On 07/08/2014 19:20, Chris Hegarty wrote: Thanks Mark, Reviewed. -Chris. P.S. At some point in the future, we should try to create a general test utility library to retrieve suitable network interfaces for tests to use. On 7 Aug 2014, at 19:15, Mark Sheppard wrote: Hi

Re: RFR: JDK-8054118 - java/net/ipv6tests/UdpTest.java failed intermittently

grand ... thanks Dmitry Mark On 07/08/2014 19:25, Dmitry Samersoff wrote: Mark, We can put nic.getDisplayName() under isWindows and save a bit of computer power. -Dmitry On 2014-08-07 22:15, Mark Sheppard wrote: Hi, please oblige and review the following fix http://cr.openjdk.java.net

RFR: JDK-8035571 - Check jdk/src/windows/native/java/net/TwoStacksPlain* for JNI pending exceptions

Message Subject: RFR: JDK-8035571 - Check jdk/src/windows/native/java/net/TwoStacksPlain* for JNI pending exceptions Date: Thu, 13 Mar 2014 20:00:30 + From: Mark Sheppard Organization: Oracle Corporation To: OpenJDK Network Dev list Hi Please oblige and review the

RFR: JDK-8044306 - java.net.Inet4AddressImpl.getLocalHostName() uses IPv6 rather than IPv4

Hi please oblige and review the small change http://cr.openjdk.java.net/~msheppar/8044306/webrev/ to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8044306 hints.ai_family is assigned AF_INET rather than AF_UNSPEC as the native function Java_java_net_Inet4AddressImpl_getL

RFR: JDK-8058932 - java/net/InetAddress/IPv4Formats.java failed because hello.foo.bar does exist

Hi Please oblige and review the following small change to test test/java/net/InetAddress/IPv4Formats.java --- a/test/java/net/InetAddress/IPv4Formats.javaTue Sep 30 13:25:04 2014 +0100 +++ b/test/java/net/InetAddress/IPv4Formats.javaTue Sep 30 15:11:05 2014 +0100 @@ -36,7 +3

Re: RFR: JDK-8058932 - java/net/InetAddress/IPv4Formats.java failed because hello.foo.bar does exist

name it twice ? {"x-" + UUID.randomUUID().toString() + "-x.x-" + UUID.randomUUID().toString() + "-x", null}, regards Mark On 30/09/2014 16:47, Daniel Fuchs wrote: On 30/09/14 17:31, Alan Bateman wrote: On 30/09/2014 08:21, Mark Sheppard wrote: Hi Please oblige

Re: RFR: JDK-8058932 - java/net/InetAddress/IPv4Formats.java failed because hello.foo.bar does exist

thanks Chris ... so shall we go with the simplest thing that works :-) i.e. somehost.some-domain ? M. On 30/09/2014 17:35, Chris Hegarty wrote: On 30 Sep 2014, at 08:47, Daniel Fuchs <mailto:daniel.fu...@oracle.com>> wrote: On 30/09/14 17:31, Alan Bateman wrote: On 30/09/2014 08

Re: RFR: JDK-8058932 - java/net/InetAddress/IPv4Formats.java failed because hello.foo.bar does exist

t;, null}, {"1024.1.2.3", null}, {"128.14.66000", null } regards Mark On 30/09/2014 18:53, Dmitry Samersoff wrote: Mark, It probably should be some-name.invalid IANA reserve .invalid TLD for tests like this one see: http://www.iana.org/ass

Re: RFR: JDK-8058932 - java/net/InetAddress/IPv4Formats.java failed because hello.foo.bar does exist

thanks Chris On 01/10/2014 15:58, Chris Hegarty wrote: Reviewed. -Chris. On 1 Oct 2014, at 00:01, Dmitry Samersoff wrote: Looks good for me! -Dmitry On 2014-10-01 02:26, Mark Sheppard wrote: Thanks Tom and Dmitry last up best dressed ... .invalid as the test domain is a good

Re: RFR: JDK-8015692 - java.net.BindException is thrown on Windows XP when HTTP server is started and stopped in the loop.

you now need to check if the selector is closed in a few places. I think it is simpler to leave the original code as is, dispatcher closes the selector, and only selectNow is invoked from stop. Or maybe I'm missing something. -Chris. On 21/02/14 12:21, Mark Sheppard wrote: Hi Chris, t

Re: RFR: JDK-8015692 - java.net.BindException is thrown on Windows XP when HTTP server is started and stopped in the loop.

Thanks Chris I'll make the changes to ServerImpl and will remove the System.out from the test regards Mark On 13/11/2014 10:49, Chris Hegarty wrote: On 12 Nov 2014, at 22:12, Mark Sheppard wrote: Hi Please oblige and review the updated patch http://cr.openjdk.java.net/~msh

Re: RFR: JDK-8015692 - java.net.BindException is thrown on Windows XP when HTTP server is started and stopped in the loop.

Hi please oblige and review the updated patch as per Chris' suggestions http://cr.openjdk.java.net/~msheppar/8015692/webrev.03/ regards Mark On 13/11/2014 10:49, Chris Hegarty wrote: On 12 Nov 2014, at 22:12, Mark Sheppard wrote: Hi Please oblige and review the updated patch

RFR: JDK-8065222 - sun/net/www/protocol/http/B6369510.java doesn't execute as expected

Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8065222/webrev/ to address the issue https://bugs.openjdk.java.net/browse/JDK-8065222 The URL construction in the test now uses InetAddress.getLocalHost().getHostName(), rather than the address.getHostName

Re: RFR: JDK-8065222 - sun/net/www/protocol/http/B6369510.java doesn't execute as expected

Hi minor update to fix, the boolean handlerRunAsExpected flag has been removed, so the fix rectifies the URL construction http://cr.openjdk.java.net/~msheppar/8065222/webrev.01/ regards Mark On 19/11/2014 19:50, Mark Sheppard wrote: Hi, please oblige and review the following change

Re: RFR: JDK-8065222 - sun/net/www/protocol/http/B6369510.java doesn't execute as expected

thanks Chris M. On 21/11/2014 22:38, Chris Hegarty wrote: Looks good, thanks Mark. -Chris On 21 Nov 2014, at 22:08, Mark Sheppard wrote: Hi minor update to fix, the boolean handlerRunAsExpected flag has been removed, so the fix rectifies the URL construction http://cr.openjdk.java.net

Re: URLStreamHandler.getHostAddress() performance

I think this raises a more fundamental question, as to why the URL hashCode() and equals() methods delegates to URLStreamHandler in the first place? rather than performing the processing within the URL class itself, and synchronizing appropriately within. If you call equals() and hasCode()

RFR: JDK-8066130 - com.sun.net.httpserver stop() throws NullPointerException if it is not started

Hi, Please oblige and review the minor change http://cr.openjdk.java.net/~msheppar/8066130/webrev/ to address the issue https://bugs.openjdk.java.net/browse/JDK-8066130 a previous amendment to com.sun.net.httpserver.ServerImpl ( https://bugs.openjdk.java.net/browse/JDK-8015692) failed to co

RFR: JDK-8039595 - closed/java/net/DatagramPacket/CheckInetAddress.java fails on macosx

Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8039595/webrev/ which addresses the failures raised in https://bugs.openjdk.java.net/browse/JDK-8039595 it should also address the CheckInetAddress test failures https://bugs.openjdk.java.net/browse/JDK-

RFR: JDK-8068597 - Add error code to to exception condition message resulting from GetAdaptersAddresses function calls

Hi please oblige and review the following additional code to src/java.base/windows/native/libnet/NetworkInterface_winXP.c webrev: http://cr.openjdk.java.net/~msheppar/8068597/webrev/ JBS item: https://bugs.openjdk.java.net/browse/JDK-8068597 which is a temporary addition to assist in the in

Re: RFR: JDK-8068597 - Add error code to to exception condition message resulting from GetAdaptersAddresses function calls

code. -Chris. On 8 Jan 2015, at 14:16, Mark Sheppard wrote: Hi please oblige and review the following additional code to src/java.base/windows/native/libnet/NetworkInterface_winXP.c webrev: http://cr.openjdk.java.net/~msheppar/8068597/webrev/ JBS item: https://bugs.openjdk.java.net/browse

RFR: JDK-8046893 - JNI exception pending in jdk/src/solaris/native/java/net: ExtendedOptionsImpl.c, PlainDatagramSocketImpl.c

Hi please review the following small change http://cr.openjdk.java.net/~msheppar/8046893/webrev/ which addresses the parfait issue in https://bugs.openjdk.java.net/browse/JDK-8046893 regards Mark

RFR: JDK-8046901 - Check jdk/src/solaris/native/sun/nio for Parfait flagged uninitialized memory

Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8046901/webrev/ which address the parfait issues in https://bugs.openjdk.java.net/browse/JDK-8046901 pertaining to uninitialized memory in src/java.base/unix/native/libnio/ch/DatagramChannelImpl.c src/java.

Re: RFR: JDK-8046901 - Check jdk/src/solaris/native/sun/nio for Parfait flagged uninitialized memory

Hi Alan, that's correct it's not an issue (false positive) as port is an out parameter, but the prescription was to initialize any flagged variables. regards Mark On 18/02/2015 15:37, Alan Bateman wrote: On 18/02/2015 15:30, Mark Sheppard wrote: Hi please oblige and

RFR: JDK-8065078 - NetworkInterface.getNetworkInterfaces() triggers intermittent test failures

Hi please oblige and review the following small change http://cr.openjdk.java.net/~msheppar/8065078/webrev/ to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8065078 the getAdapters and getAdpater functions were amended in to add additional diagnostic of the error code,

Re: RFR: JDK-8065078 - NetworkInterface.getNetworkInterfaces() triggers intermittent test failures

thanks for the review Chris regards Mark On 05/03/2015 14:09, Chris Hegarty wrote: On 4 Mar 2015, at 21:53, Mark Sheppard wrote: Hi please oblige and review the following small change http://cr.openjdk.java.net/~msheppar/8065078/webrev/ I agree with the increased buffer size, and the

RFR: JDK-8041677 - java/net/MulticastSocket/TestInterfaces failed on Oracle VM Virtual Ethernet Adapter

Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8041677/webrev/ which addresses the issue https://bugs.openjdk.java.net/browse/JDK-8041677 analysis has shown that the Teredo interfaces causes issue, due to its dynamic configuration, when included in the t

RFR: JDK-8077377 - java/net/MulticastSocket/SetOutgoingIf.java fails intermittently with NullPointerException

Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8077377/webrev/ to address the issue https://bugs.openjdk.java.net/browse/JDK-8077377 it is possible that "stray" packets can be received in this MulticastSocket test, and this results in a NPE from the Net

Re: RFR: JDK-8041677 - java/net/MulticastSocket/TestInterfaces failed on Oracle VM Virtual Ethernet Adapter

Thanks Alan On 26/05/2015 20:34, Alan Bateman wrote: On 26/05/2015 20:21, Mark Sheppard wrote: Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8041677/webrev/ which addresses the issue https://bugs.openjdk.java.net/browse/JDK-8041677 analysis has shown

Re: RFR: JDK-8077377 - java/net/MulticastSocket/SetOutgoingIf.java fails intermittently with NullPointerException

can remove the commented throw regards Mark On 26/05/2015 20:43, Alan Bateman wrote: On 26/05/2015 20:34, Mark Sheppard wrote: Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8077377/webrev/ to address the issue https://bugs.openjdk.java.net/browse/

Re: RFR: JDK-8041677 - java/net/MulticastSocket/TestInterfaces failed on Oracle VM Virtual Ethernet Adapter

. On 26 May 2015, at 20:21, Mark Sheppard wrote: Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8041677/webrev/ which addresses the issue https://bugs.openjdk.java.net/browse/JDK-8041677 analysis has shown that the Teredo interfaces causes issue, due to

RFR: JDK-8129507 - sun/net/www/protocol/http/B6369510.java fails intermittently

Hi Please oblige and review the change below which addresses the issue https://bugs.openjdk.java.net/browse/JDK-8129507 This amends the url.openConnection() to take the Proxy.NO_PROXY argument, so that a direct connection is made to test http server, thus bypassing any configured and enabled

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

a couple of other considerations in the context of this issue perhaps? in this s is being duped onto fd, and part of the dup2 operation is the closing of fd, but what's is the expected state of file descriptor fd in the event of a dup2 failure? s is closed in any case, but what about fd, sho

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

the RESTARTABLE loop will return another error. On 08/09/2015 09:28, Chris Hegarty wrote: On 7 Sep 2015, at 17:41, Mark Sheppard wrote: a couple of other considerations in the context of this issue perhaps? in this s is being duped onto fd, and part of the dup2 operation is the closing of

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

ent call in the RESTARTABLE loop will return another error. On 08/09/2015 09:28, Chris Hegarty wrote: On 7 Sep 2015, at 17:41, Mark Sheppard wrote: a couple of other considerations in the context of this issue perhaps? in this s is being duped onto fd, and part of the dup2 operation is th

Re: RFR 4906983: java.net.URL constructors throw MalformedURLException in undocumented way

Hi I don't think the URL string http://server:-1/path can be considered a valid URL as the port value -1 is not legal port value. However, the URL class doesn't object and throw a MalformedURLException, which is something of an anomaly, caused by the spec allowing a port value of -1 for the

Re: RFR 4906983: java.net.URL constructors throw MalformedURLException in undocumented way

I was thinking as a change for all constructors, as there are URL, which may overload authority part's structural elements such that port might be a "remote object id", or some other form of token. OK, that's fine On 13/09/2015 15:25, Chris Hegarty wrote: Is this suggested wording for the “s

Re: RFR: 8135305: InetAddress.isReachable reports true when loopback interface is specified

Hi Rob, looks fine ... the "him" variable in the Java_java_net_Inet4AddressImpl_isReachable0 would appear not to be used now, so could probably be removed with its call on memset ? regards Mark On 24/09/2015 15:45, Rob McKenna wrote: Please ignore the formatting errors. Thats either a

Re: SO_REUSEPORT feature support in JDK 9 for socket communication

the following JBS item exists: https://bugs.openjdk.java.net/browse/JDK-6432031 search of windows documentation suggests that SO_REUSEPORT is still not an option man setsockopt on Solaris shows it as an option, but without precise description of semantics regards Mark On 22/10/2015 14:33,

RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

Hi, please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8134577/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8134577 the operative word has been "eliminate". As such, the interface and service descriptor sun.net.spi.namese

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

ot;mapping" is more than one to avoid a possible ArrayIndexOutOfBoundsException. Looks like those methods may also be static. Artem On 10/26/2015 02:32 AM, Mark Sheppard wrote: Hi, please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8134577/webrev/ which address th

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

On 27/10/2015 15:05, Alan Bateman wrote: On 25/10/2015 23:32, Mark Sheppard wrote: Hi, please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8134577/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8134577 the operative word has been &

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

Hi Max, thanks for the reply. I'll change the hosts file names used to correspond with an associated test dynamic update of host / ip mappings updates are accommodated as seen per the tests http://cr.openjdk.java.net/~msheppar/8134577/webrev/test/sun/net/InetAddress/nameservice/simple/Defa

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

Hi, based on feedback from first review the updates have been amended please oblige and review the current set of changes as per http://cr.openjdk.java.net/~msheppar/8134577/webrev.02/ regards Mark On 25/10/2015 23:32, Mark Sheppard wrote: Hi, please oblige and review the following

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

hosts file name in tests changed to TestHosts to avoid any potential confusion with /etc/hosts regards Mark On 12/11/2015 16:46, Mark Sheppard wrote: Hi, based on feedback from first review the updates have been amended please oblige and review the current set of changes as per http

Re: Patch for adding SO_REUSEPORT socket option

there would appear to be a link to a webrev in the JBS bug https://bugs.openjdk.java.net/browse/JDK-6432031 http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.01/ I presume t

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

g structure, as per /etc/hosts ? do we wish that a list of ip addresses are returned, even if tests don't currently need it ? regards Mark On 22/11/2015 09:56, Alan Bateman wrote: On 12/11/2015 16:46, Mark Sheppard wrote: Hi, based on feedback from first review the updates have

Re: Request for review & approval: 8141260: isReachable crash in windows xp

yes, the fix looks fine, and I verified the individual isReachable test on the test host where it failed. it is possible to refactor the function Java_java_net_Inet4AddressImpl_isReachable0 a little, by extracting the newly re-introduced "else" block into its own function e.g. wxp_ping4 su

Re: 8143397: It looks like InetAddress.isReachable(timeout) works incorrectly

Hi Rob, change looks fine and handles the MS idiosyncrasies neatly change works fine ... consistent responses and failing test returns expected results regards Mark On 09/12/2015 01:44, Rob McKenna wrote: The intention of the 2nd revision of the fix is to make the undocumented 1000ms

Re: RFR 4906983: java.net.URL constructors throw MalformedURLException in undocumented way

bs up review result from Chris Hegarty for an older patch http://cr.openjdk.java.net/~dbuck/4906983.1/ (pending the outcome of the mail-exchange with Mark-Sheppard). @Chris: Am i right in my assumption? Is this still valid? The result on the pending mail-exchange is in the http://cr.openjdk.jav

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

statements removed hosts file name in tests changed to TestHosts to avoid any potential confusion with /etc/hosts regards Mark On 12/11/2015 16:46, Mark Sheppard wrote: Hi, based on feedback from first review the updates have been amended please oblige and review the current set of changes as

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

/01/2016 07:40, Alan Bateman wrote: On 31/12/2015 14:30, Mark Sheppard wrote: Hi please oblige and review the current version of the fix for https://bugs.openjdk.java.net/browse/JDK-8134577 at http://cr.openjdk.java.net/~msheppar/8134577/webrev.05/ which is based on feedback from the second

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

05/01/2016 00:54, Mark Sheppard wrote: Hi, as per feedback below webrev has been updated http://cr.openjdk.java.net/~msheppar/8134577/webrev.06/ change summary: * List nameServices replaced with Nameservice nameService * references to nameServices removed * private interface NameService

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

removed references to JNDI added test for non-existent hosts file regards Mark On 06/01/2016 20:37, Alan Bateman wrote: On 06/01/2016 15:37, Mark Sheppard wrote: thanks for the feedback, Alan based on suggestions, all issues have been addressed and patch has been updated http

RFR: JDK-8147862 - Null check too late in sun.net.httpserver.ServerImpl

Hi please oblige and review the small change http://cr.openjdk.java.net/~msheppar/8147862/webrev/ to address https://bugs.openjdk.java.net/browse/JDK-8147862 it was observed that a null check on a SocketChannel object in the Disptacher.run() method within ServerImpl, should be earlier in the

Re: [PING] RFR: JDK-8135259: InetAddress.getAllByName only reports "unknown error" instead of actual cause

FWIW the src is restructured in JDK9, but equivalent changes exist src/java.base/unix/native/libnet/net_util_md.c src/java.base/unix/native/libnet/net_util_md.h regards Mark On 12/02/2016 11:28, Chris Hegarty wrote: On 12/02/16 11:09, Ramanand Patil wrote: Hi Sean, Since I saw the conventi

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

ments, along with some stylistic and proposed re-wordings, into a webrev for your convenience: http://cr.openjdk.java.net/~chegar/8134577_comments/src/java.base/share/classes/java/net/InetAddress.java.sdiff.html -Chris. On 07/01/16 15:38, Alan Bateman wrote: On 07/01/2016 10:44, Mark She

Re: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c

the declaration in of plen (also scope and dad_status) as an int in enumIPv6Interfaces would appear to be done to align with its use in fscanf, even though it is a two character conversion. So would it not be more appropriate to cast it as a short when passed to addif ? the name plen would als

Re: RFR 8157811 [9] Additional minor fixes and cleanups in NetworkInterface.c

Hi Chris, the fix for 8068028 was marked 9-na for some reason, as such afaik the changes were not propagated to JDK9, which changed its src tree structure at that time (i think, jdk8 were on solaris files), parfait may not have highlighted them in that context afaik the other changes in tha

Re: RFR [9] 8085785: sun/net/www/protocol/http/ZoneId.java timeout intermittently

Hi Chris, this looks good ... so the server now listens on wildcard and the client uses IPv6 loopback as the destination address. The use of NO_PROXY, is good. I wouldn't have thought of that, and in the past, Tests have experienced firewall issues on linux and macos perviously without this

Re: RFR 8158023: SocketExceptions contain too little information sometimes

Hi, wrt JNU_ThrowByNameWithMessaheAndLastError, it would appear that it doesn't allow for malloc to fail and hence str1 could be null and a problematic input to jio_snprintf which could result in a de-referencing of zero. in the call flow would it not be more appropriate to manipulate nat

Re: RFR 8158023: SocketExceptions contain too little information sometimes

Hi Christoph, thanks for the response ... yes, you do check the getLastErrorString return ... sorry about that! regards Mark On 27/06/2016 14:28, Langer, Christoph wrote: Hi Mark, thanks for looking at this. Please see my comments inline. wrt JNU_ThrowByNameWithMessaheAndLastErro

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

Hi perhaps there is an opportunity to do some refactoring here (... for me a "goto " carries a code smell! ) along the lines if (timeout) { nread = NET_ReadWithTimeout(...); } else { nread = NET_Read(...); } the NET_ReadWithTimeout (...) function will contain a restructuring of

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

tml>). I incorporated the review comments. Thanks, Vyom On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote: Hi perhaps there is an opportunity to do some refactoring here (... for me a "goto " carries a code smell! ) along the lines if (timeout) { nread = NET

Re: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation

have had a look through the changes twice, and they look fine ... i'll apply the patch and run a regression build to confirm the moving of int flags on 919 to a conditional block, I expect to cause a strict compile error in my solaris env, so need to check that regards Mark On 02/09/2016

Re: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation

builds and regression tests appear to be OK with the proposed changes. regards Mark On 02/09/2016 12:41, Mark Sheppard wrote: have had a look through the changes twice, and they look fine ... i'll apply the patch and run a regression build to confirm the moving of int flags on 919

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

484/webrev0.1/index.html>). I incorporated the review comments. Thanks, Vyom On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote: Hi perhaps there is an opportunity to do some refactoring here (... for me a "goto " carries a code smell! ) along the lines if (timeout) {

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

mments. Thanks, Vyom On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote: On 05/09/16 15:37, Mark Sheppard wrote: if the desire is to avoid making double calls on gettimeofday in the NET_ReadWithTimeout's while loop for its main call flow, Yes, the desire is to make no mo

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

e poll/select returns before the timeout? Just an idea. -Chris. Thanks, Vyom On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote: On 05/09/16 15:37, Mark Sheppard wrote: if the desire is to avoid making double calls on gettimeofday in the NET_ReadWithTimeout's while loop for its mai

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

Hi Chris, so are you accepting that it is correct to add the overridden methods in MulticastSocket and that these need appropriate javadoc ? or are you advocating pushing the handing of the SO_REUSEPORT into the base DatagramSocket class ? It is not clear how your code changes fit in th

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

hen raises the question of why have a convenience method, such as setReuseAddress() in the first place, when it can be handled adequately via the setOption regards Mark On 14/09/2016 13:34, Chris Hegarty wrote: Mark, On 14/09/16 13:23, Mark Sheppard wrote: Hi Chris, so are you accepting

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

le, opt-in from new code, by creating an unbound MS, setting the option, then binding. -Chris. On 14/09/16 14:47, Chris Hegarty wrote: Mark, On 14/09/16 14:22, Mark Sheppard wrote: Hi Chris, I don't fully understand your objections to the approach taken. Is there a compatibility

  1   2   3   >