Re: JEP 321: HTTP Client (Standard)

On 04/12/2017 18:41, David Lloyd wrote: : Speaking *solely* in the interests of platform quality and integrity, I think that before _any_ high-level non-blocking/asynchronous protocol API is ever introduced into the platform, it would be an incredible waste to not have some kind of design consult

Re: JEP 321: HTTP Client (Standard)

On 04/12/2017 21:56, David Lloyd wrote: : I've had opportunity to give feedback, perhaps, though the API always seemed incomplete. At least nobody (that I saw) sent out a message saying "Here it is, it's all done, what do you think?". I've certainly never had opportunity to try it out: given it

Re: RFR: 8193034: Optimize URL.toExternalForm

On 05/12/2017 04:01, Martin Buchholz wrote: http://cr.openjdk.java.net/~martin/webrevs/jdk/URL.toExternalForm/ The style is interesting but I don't see anything obvious wrong. -Alan

Re: JEP 321: HTTP Client (Standard)

On 07/12/2017 00:19, James Roper wrote: : One issue that I'm not sure about is the consequences of using direct buffers with regards to garbage collection. If direct buffers are never copied onto the heap, and are never reused, lets say you're just implementing a proxy passing buffers through

Re: RFR 8185027: Typo in java.net.URLClassLoader.findResources(String) method documentation

On 12/12/2017 10:27, Chris Hegarty wrote: The returns section of the java.net.URLClassLoader.findResources(String) method documentation, contains the following sentence:    "an Enumeration of URLs If the loader is closed, the Enumeration     will be empty." should be replaced by:    "An Enumerati

Re: RFR 8185027: Typo in java.net.URLClassLoader.findResources(String) method documentation

On 12/12/2017 10:40, Chris Hegarty wrote: - * @return an {@code Enumeration} of {@code URL}s - * If the loader is closed, the Enumeration will be empty. + * @return An {@code Enumeration} of {@code URL}s. + * If the loader is closed, the Enumeration contains no

Re: RFR: 8193034: Optimize URL.toExternalForm

On 11/12/2017 17:24, Martin Buchholz wrote: There's now a Martin-style benchmark at http://cr.openjdk.java.net/~martin/webrevs/jdk/URLMicroBenchmark/ that suggests the code is ~ 25% faster with default JVM flags (C2) but ~ 25

Re: does the underlying implementation (not public) of DatagramSocketImp's send receive method busy wait

On 18/12/2017 21:24, Paul Marks wrote: So if the kernel decides to block, the thread will be suspended (consuming no CPU) until it's done. However, the UDP protocol has no concept of flow control, so blasting out packets without any rate limit or acknowledgement mechanism is not a good ide

Re: Adding SocketChannel toString to connection exception messages

On 29/12/2017 00:33, Steven Schlansker wrote: Thanks for the discussion! So, it sounds like amending the message by default is going to be a non-starter -- but at least adding the information otherwise might be possible. There are examples in other area where exceptions include detail informa

Re: Adding SocketChannel toString to connection exception messages

On 02/01/2018 21:25, Steven Schlansker wrote: : This would definitely be better than nothing! But it's still difficult, for example a common allocation pattern for us would be to assign networks to availability zones: 10.0.1.0/24 10.0.2.0/24 10.0.3.0/24 then if you pick the same last number

Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

On 07/02/2018 17:31, Chris Hegarty wrote: Gary, http://cr.openjdk.java.net/%7Egadams/8080990/webrev.02/ I think the replacement of WSASendDisconnect with shutdown(SD_SEND) should be fine. I do note that there is another usage of WSASendDisconnect in java.base/windows/native/libnet/net_util_md.

Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

On 07/02/2018 18:02, gary.ad...@oracle.com wrote: Yes, WSASendDisconnect is deprecated in vs2013. As far as I know "shutdown(fd, SD_SEND)" prevents further outgoing writes and there was no final payload to send. I have not seen any failures in the java/nio tests. Okay, I guess it should okay bu

Re: WebSocket

On 19/02/2018 20:19, Simone Bordet wrote: : Now, ByteBufferInputStream is not present in the JDK, and if you want to complain you are in good (and conspicuous) company, as the JDK engineers appear to avoid the issue since years now (e.g. create a String from a ByteBuffer without copy). There is

Re: WebSocket

On 20/02/2018 08:14, Simone Bordet wrote: : Where would be a good list to start discussing ByteBuffer to [Input|Output]Stream bridging ? Are you looking for this for performance or convenience reasons? Bridging channel and input/output streams is natural of course, bridging between buffers a

Re: upgrade to jdk6 com.sun.httpserver

On 20/02/2018 19:52, David Lloyd wrote: enough that the internal server is almost a legacy artifact at this point (after all it was IIRC only introduced to support the in-JDK web services classes which may soon be dropped from the JDK altogether). Yes, the original motive for this small HTTP serv

Re: RFR 8199437 [11]Improve diagnostic system assertion message in com.sun.net.httpserver impl

Looks good. On 14/03/2018 13:16, Chris Hegarty wrote: An odd assertion has been observed in the com.sun.net HTTP Server code, that is currently unexplainable. I'd like to add some additional diagnostics information to the assertion so that it may be more helpful if seen again. --- a/src/jdk.ht

8199329: Remove code that attempts to read bytes after connection reset reported

Classic networking has some curious code to deal with connection resets. I needed to dig into ancient history to find the issues and original motivations. When a connection reset is reported (usually ECONNRESET) then further attempts to read from the socket will typically return -1 (EOF). Cl

Re: RFR 8199437 [11]Improve diagnostic system assertion message in com.sun.net.httpserver impl

We can add a toString() to SelectionKeyImpl if needed as it can access the interest and readys ops without concern for cancel. -Alan On 14/03/2018 14:51, Chris Hegarty wrote: On 14/03/18 14:39, Daniel Fuchs wrote: Hi Chris, key.interestOps() might throw CancelledKeyException in which case yo

Re: RFR 8199437 [11]Improve diagnostic system assertion message in com.sun.net.httpserver impl

On 14/03/2018 15:11, Chris Hegarty wrote: On 14/03/18 14:58, Alan Bateman wrote: We can add a toString() to SelectionKeyImpl if needed as it can access the interest and readys ops without concern for cancel. Yes, that would be fine either. Since you have an outstanding review that contains

Re: RFR of JDK-8199215: Re-examine getFreePort method in test infrastructure library

On 15/03/2018 08:43, Hamlin Li wrote: : Hi Alan, Thank you for reviewing, I have updated the webrev in place. ( cc'ing serviceability-dev and net-dev as these are the other areas that use the getFreePort method in the test library. For context, the patch that we are discussing is:     http:/

Re: RFR of JDK-8199215: Re-examine getFreePort method in test infrastructure library

On 16/03/2018 01:54, Hamlin Li wrote: : Hi Alan, Thank you for detailed reviewing. I have updated the webrev in place. (http://cr.openjdk.java.net/~mli/8199215/webrev.00/) Looks good, just a minor typo "is better choice" -> "is a better choice". Just to confirm, have you run the serviceabilit

Re: RFR of JDK-8199215: Re-examine getFreePort method in test infrastructure library

On 16/03/2018 09:00, Hamlin Li wrote: : Just to confirm, have you run the serviceability and http client tests to make sure that they compile with this change? Yes, I ran tier1,tier2,tier3 tests(I think it includes httpclient tests), and also specific tests using Utils.getFreePort in svc ar

Re: RFR 8200181 [11] Remove superflous non-IPv4 code from Java_java_net_TwoStacksPlainSocketImpl_socketListen

On 23/03/2018 17:18, Chris Hegarty wrote: Given that JDK-8058965 removed the IPv6 support from TwoStacksPlainSocketImpl, the native socketListen method no longer needs to deal with the non-IPv4 code path. This simplifies the code, brings it in line with the unix variants, and removes a possible

Re: RFR [11] 8198358 : Align organization of DualStackPlainSocketImpl with TwoStacksPlainSocketImp [win]

On 25/03/2018 19:13, Ivan Gerasimov wrote: : In the code above, newfd was obtained from a call to accept() a few lines before this check. So, the Java code has no way of being aware of this socket, and it will never be closed unless we do it right here, before returning -1. The SocketImpl

Re: RFR [11] 8200304: TwoStacksPlainDatagramSocketImpl and socket cleaner

On 28/03/2018 10:08, Chris Hegarty wrote: 8195059 [1] updated the socket implementation to use a cleaner, rather than the previous finalizer implementation. Unfortunately the TwoStacksPlainDatagramSocketImpl on Windows, that uses two native file descriptors, may close one or other when binding, o

Re: RFR [11] 8200304: TwoStacksPlainDatagramSocketImpl and socket cleaner

On 29/03/2018 11:10, Chris Hegarty wrote: : This is much simpler. @Override protected synchronized void bind0(int lport, InetAddress laddr) throws SocketException { + // The native bind0 may close one or both of the underlying file + // descr

Re: RFR [11] 8200304: TwoStacksPlainDatagramSocketImpl and socket cleaner

On 29/03/2018 15:05, Chris Hegarty wrote: : Good catch. The !ipv6_supported case has been updated to close the socket and set the fd to null. Given that the cleaner is unregistered, and the fd is null ( close will effectively be a no-op ), it should be fine. http://cr.openjdk.java.net/~chegar/82

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

On 13/04/2018 10:50, vyom tewari wrote: Hi All, Please review the below code. BugId    : https://bugs.openjdk.java.net/browse/JDK-8194298 webrev : http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html Currently Java supports SO_KEEPALIVE, whose default value is 7200 seconds which

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

On 14/04/2018 08:09, Alan Bateman wrote: : Can you update SocketChannel/SocketOptionTests.java to ensure that SocketChannel is test? We also need to ensure that the new options don't show up in the supportedOptions returned by the channels that don't support these new options. Ju

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

On 23/04/2018 13:05, vyom tewari wrote: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.1/index.html). I incorporated  most of the review comments. This looks much better but I think the second paragraph of the spec of each option needs to be inverted so

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

On 10/05/2018 16:21, vyom tewari wrote: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.2/index.html). I incorporated most of the review comments. Chris as you suggested in below mail i did not added the note for upper-bound because values are also OS sp

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

On 11/05/2018 19:31, Chris Hegarty wrote: : P.S. A separate issue, but when reviewing this it reminded me that we should deprecate-for-removal jdk/net/Sockets.java. It’s functionality is already supported by a standard API. I think just the methods rather than the class. Lucy Yingqi is working

Re: Behaviour of SocketChannelImpl.close() in Java11 (ea+12)

(cc'ing nio-dev as as this is asking about SocketChannel). On 11/05/2018 19:10, Norman Maurer wrote: Hi all, I recently started to test Netty [1] with Java11 and found that we have two tests that are currently failing due some changes in Java 11 compared to earlier versions. I wanted to get

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

On 12/05/2018 10:21, vyom tewari wrote: : Thanks for review, please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.4/index.html). I've skimmed through this webrev. The spec for the new options mostly look good but all three include "The exact semantics of this so

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

On 14/05/2018 16:30, vyom tewari wrote: Hi All, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.5/index.html). Only change with the previous wrev(04) is i removed "socket type" as Alan suggested and used the default  constructor (Set> options = new HashSe

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

On 15/05/2018 08:35, Langer, Christoph wrote: I’m asking because I’m planning to add some AIX options and will have to choose a name for this implementation eventually. @Alan: What do you think? Yes, I agree it should be renamed. Vyom has just finalized the CSR so I assume the final points

Re: RFR [11] 8203297: java/net/URL/OpenStream.java fails intermittently

On 23/05/2018 16:43, Chris Hegarty wrote: This is a review for a trivial change to a test to make it more robust on platforms, Mac, where system proxies are used by HttpURLConnection, by default. This test should never use a proxy. This looks okay to me.

Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

On 24/05/2018 21:57, Ivan Gerasimov wrote: Hello! On Unix systems several system calls (including pread, read, readv, recvfrom, recvmsg, send, sendfile, sendmsg, sendto) may set errno to either EAGAIN or EWOULDBLOCK on the same condition. On Linux these two constants are the same, but they a

Re: Problem with half-closure related to connection-reset in Java 11

On 29/05/2018 14:52, Norman Maurer wrote: Hi all, After trying to run our testsuite in Netty [1] with Java11+ea15 I noticed we have one failing test that seems to be related to: https://bugs.openjdk.java.net/browse/JDK-8199329 http://hg.openjdk.java.net/jdk/jdk/rev/92cca24c8807 I think the c

Re: Problem with half-closure related to connection-reset in Java 11

On 29/05/2018 15:26, Norman Maurer wrote: : Yes thats what I am saying… I think if a write fails due a connection-reset a read should still be possible until we are told by the OS that we also hit an error here. Honestly I think this scenario can happen quite often in reality where some soft

Re: Problem with half-closure related to connection-reset in Java 11

On 29/05/2018 17:28, Norman Maurer wrote: : Oh sorry I thought thats the right system to use. I just followed the wiki page (I think). bugs.sun.com or bugreport.java.com is the right place. That routes the bugs to the JIRA, just not automatically to the right project as often issues need to be

Re: Problem with half-closure related to connection-reset in Java 11

On 31/05/2018 18:08, Norman Maurer wrote: : [1] https://bugs.openjdk.java.net/browse/JDK-8203937 Also let me know if you need anything else or want me to test something I saw your other mail where you posted a link to giithub. I should have replied to ask you to attach the test so that it

Re: Problem with half-closure related to connection-reset in Java 11

On 01/06/2018 10:21, Florian Weimer wrote: On 05/29/2018 04:26 PM, Norman Maurer wrote: Yes thats what I am saying… I think if a write fails due a connection-reset a read should still be possible until we are told by the OS that we also hit an error here. Are there implementations where the k

Re: Problem with half-closure related to connection-reset in Java 11

On 01/06/2018 13:19, Florian Weimer wrote: But there is a race, even on Linux.  If the network is fast enough and you get an RST segment from the other end, kernel the receive buffer is discarded. Right although it can be a bit more predictable with loopback connections. So whatever you

8203937: Not possible to read data from socket after write detects connection reset

This is a follow-up to the "Problem with half-closure related to connection-reset in Java 11" thread that we've been discussing here over the last few days. As we discussed, you can't reliably rely on being able to read bytes after the connection reset but it is a reminder that a subtle behavio

Re: java.net.Socket should report the attempted address and port

On 06/06/2018 08:45, Michael McMahon wrote: Hi all, Finally to return to this topic. We have looked at a few different approaches and it seems the best way is to define a security property that can be set in the java.security configuration file, but which can be overridden as a system property

Re: java.net.Socket should report the attempted address and port

On 15/06/2018 11:53, Péter Gergely Horváth wrote: Hi Michael, I am wondering if the property name could be maybe improved: 1.) The prefix "jdk" does not seem to match the naming convention that of the existing networking properties [1], where for example prefix "java.net "

Re: java.net.Socket should report the attempted address and port

On 18/06/2018 13:15, Michael McMahon wrote: Hi all, I agree with Sean's suggestion below that a multi-valued property captures the generality in the name and the specific case implemented here with the value "hostInfo". So, how about exactly as suggested: property name - "jdk.net.includeInExc

Re: java.net.Socket should report the attempted address and port

On 19/06/2018 10:30, Michael McMahon wrote: Hi, There is an updated webrev for this at: http://cr.openjdk.java.net/~michaelm/8204233/webrev.2/ I'd like to get this into 11 and it needs a CSR to approve the property name change. So, hopefully it can be reviewed quickly. A coin toss as to whethe

Re: RFR: 8205342: windows : potential memleaks in getAdapter(s) in NetworkInterface_winXP.c

On 20/06/2018 09:07, Baesken, Matthias wrote: Hello . Please review this small  fix that  fixes  potential  memory leaks in  getAdapter(s) in NetworkInterface_winXP.c  and simplifies the coding a bit too . Currently   when generating error messages ,   some memory  is malloc-ed  for the e

Re: RFR: 8205342: windows : potential memleaks in getAdapter(s) in NetworkInterface_winXP.c

On 25/06/2018 15:20, Baesken, Matthias wrote: Hi Ivan ,  I removed the memset calls as suggested by Thomas , makes the change  even a little bit shorter ; and replaced the  fix  “100” by sizeof   in the print calls . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8205342.2/

Re: RFR: 8205397 - InetAddress has wrong declaration for readObjectNoData

On 27/06/2018 18:09, Daniel Fuchs wrote: Hi, Please find below a trivial fix for: https://bugs.openjdk.java.net/browse/JDK-8205397 8205397: InetAddress has wrong declaration for readObjectNoData webrev: http://cr.openjdk.java.net/~dfuchs/webrev-8205397.00/ Looks good. -Alan

Re: RFR : 8205959 : Do not restart close if errno is EINTR

On 28/06/2018 00:15, Ivan Gerasimov wrote: Hello! When closing a socket via NET_SocketClose(int fd), a close(fd) is called. The later is wrapped in a retry-loop, which is wrong because close() is not restartable. The `man 2 close` states: """ ... close() should not be retried after an EINTR s

Re: RFR : 8205959 : Do not restart close if errno is EINTR

On 28/06/2018 17:35, David Lloyd wrote: : Do you (or Alan) think that this might have accounted for real-world connection problems? In the file I/O area, with NFS I think, we had an issue a long time ago where close was retried after EIO. That issue was fixed a long time ago but it's one that

Re: [12] 8194899: Remove unused sun.net classes

On 02/07/2018 18:21, Brian Burkhalter wrote: https://bugs.openjdk.java.net/browse/JDK-8194899 The proposed change is to remove these classes which are unused in the JDK: sun.net.NetworkServer sun.net.URLCanonicalizer Should be okay, assuming the JDK builds and there aren't any tests using

Re: [PATCH] SOCK_CLOEXEC for opening sockets

On 10/07/2018 17:40, Martin Buchholz wrote: I agree with this approach - it parallels the efforts made with O_CLOEXEC in past years. According to https://www.freebsd.org/cgi/man.cgi?query=socket&sektion=2 SOCK_CLOEXEC is also available on freebsd. This is something that doesn't come up too oft

Re: [PATCH] SOCK_CLOEXEC for opening sockets

/net_util_md.h    Tue Jul 10 23:32:21 2018 -0700 @@ -89,6 +89,7 @@ int NET_Writev(int s, const struct iovec * vector, int count); int NET_Connect(int s, struct sockaddr *addr, int addrlen); int NET_Accept(int s, struct sockaddr *addr, socklen_t *addrlen); +int NET_SocketOpen(int domain, int type, in

Re: [PATCH] SOCK_CLOEXEC for opening sockets

On 12/07/2018 05:55, Andrew Luo wrote: Ok, fixed a few more places (and a bug where fcntl was being run on a -1 fd).  Patch is below, let me know if there’s any other suggestions/etc. The file system code should not be calling into NET_* functions. The changes to net_util_* will also need cl

Re: [PATCH] SOCK_CLOEXEC for opening sockets

On 12/07/2018 08:21, Andrew Luo wrote: Thanks, I can refactor it.  I’m not as familiar with the OpenJDK architecture – should I just duplicate the function into libnio or is there some common utility library that I should move it into?  Also, let me know what in net_util_* needs cleanup.  The

Re: [PATCH] SOCK_CLOEXEC for opening sockets

On 17/07/2018 07:33, Andrew Luo wrote: Great, thanks. By the way, I do see other places where we use NET_* functions in libnio, but if you prefer that I duplicate that code instead, It's okay for the code in libnio/ch to use the NET_* functions. The issue is the changes to libnio/fs which is t

Re: [PATCH] SOCK_CLOEXEC for opening sockets

On 24/07/2018 21:34, Chris Hegarty wrote: On 19 Jul 2018, at 18:41, Andrew Luo wrote: Just checking - is there any other changes that I should make to the patch, or anything else you guys need me to do? A webrev genderated from Andrew’s patch along with: 1) some additional includes of “ne

Re: [PATCH] SOCK_CLOEXEC for opening sockets

On 25/07/2018 13:49, Chris Hegarty wrote: : The updates to the various site to use the NET_* functions are fine. However, I think the new functions in net_util_md.c could be cleaner. I think it would be better to fallback to socket/socketpair + fcntl when the initial call fails with EINVAL.

Re: [openjdk-x] Bind to a multicast address fails

On 07/09/2018 10:49, Decke, Hendrik (K-GERFA/A) wrote: Hello, it seems one of our external developers (Andre Naujoks, CC) found a bug while binding a IPv6 multicast UDP-socket for one of our projects. Since this seems to be a fundamental bug (from our perspective), we address this directly

Re: [openjdk-x] Bind to a multicast address fails

On 07/09/2018 12:33, Andre Naujoks wrote: : Hi Alan. First of all, thank you for the quick reply. I was not aware, that there was actually a bug opened for that issue. The join is not the problem at this point. We need to bind the socket to the address to avoid receiving traffic from all multic

Re: [openjdk-x] Bind to a multicast address fails

On 07/09/2018 13:22, Andre Naujoks wrote: : I have not tried joining IPv4 groups on an IPv6 socket through java, since we do not use IPv4 at all in this particular environment. I have tried setting IP_MULTICAST_ALL to 0 in the IPv6 scenario (in a C++ project), hoping it would help, but it did not

Re: [openjdk-x] Bind to a multicast address fails

On 10/09/2018 14:53, Chris Hegarty wrote: On 10/09/18 10:22, vyom tewari wrote: ... Hi Andre, i will apply your patch run our all network tests. I will update once i will have result. The patch in question is in the description of https://bugs.openjdk.java.net/browse/JDK-8210493, correct?

Re: [openjdk-x] Bind to a multicast address fails

On 12/09/2018 10:09, vyom tewari wrote: Hi Alan,Chris, I imported the Andre's patch and our all existing internal tests are clean. Good to hear! Next step will be to add or extend existing tests to cover binding to both IPv4 and IPv6 multicast addresses. The Promiscuous tests (one for Mu

Re: RFR [12] 8211099: ProblemList two networking tests until jtreg b14 is promoted

Looks fine. On 25/09/2018 14:46, Chris Hegarty wrote: The following two networking tests have an issue when jtreg performs its post-run clean up actions ( which is tracked by 8208690 ). The jtreg issue, 7902259, has been fixed but is not yet in a promoted build. Re-ProblemList two networking te

Re: RFR : 8211146 : fix problematic elif-tests after recent gcc warning changes Werror=undef

On 26/09/2018 10:24, Baesken, Matthias wrote: Hello, please review this small build fix . After the recent changes  to  the gcc compile flags   with  8211029    , most of our  Linux builds stopped working . Error : === Output from failing command(s) repeated here === * For target support

Re: RFR [12] 8211902: broken link in java.net.http.WebSocket.Builder

On 09/10/2018 12:03, Chris Hegarty wrote: Trivially, this link should refer to HttpClient, rather than HttpRequest. --- a/src/java.net.http/share/classes/java/net/http/WebSocket.java +++ b/src/java.net.http/share/classes/java/net/http/WebSocket.java @@ -197,7 +197,7 @@         * {@link Securi

Re: RFR [12] 8212000: Verify exported symbols in java.base (libnet, libnio/ch)

On 10/10/2018 12:46, Pavel Rappo wrote: Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8212000/webrev.00/8212000/ This is a clean-up kind of change. It seals unnecessarily exported functions from libnet and libnio, and also removes an unused declaration from l

Re: RFR: 8189366: SocketInputStream.available() should check for eof

On 11/10/2018 09:03, vyom tewari wrote: Hi Chris, Thanks for review, please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8189366/webrev0.1/index.html) where i included the test. Can you explain the behavior change for the closed socket case? Will this change mean that available

Re: RFR: 8189366: SocketInputStream.available() should check for eof

On 12/10/2018 14:43, David Lloyd wrote: On Fri, Oct 12, 2018 at 6:01 AM Chris Hegarty wrote: That is correct. While not intuitive, I don't propose that we change this. ( if this were a new implementation then I think it should throw IOE for this scenario, but we are where we are ). I am glad t

Re: 8213210: Change ServerSocket(SocketImpl impl) constructor to protected access

On 31/10/2018 19:13, Brian Burkhalter wrote: https://bugs.openjdk.java.net/browse/JDK-8213210 Please see diff included below. CSR to follow. One thing to check is whether ServerSocket specifies null handling anywhere. I don't think it does so you might have to add an @throws NPE. -Alan

Re: 8213210: Change ServerSocket(SocketImpl impl) constructor to protected access

On 31/10/2018 19:26, Brian Burkhalter wrote: On Oct 31, 2018, at 12:20 PM, Brian Burkhalter mailto:brian.burkhal...@oracle.com>> wrote: -   ServerSocket(SocketImpl impl) { +   protected ServerSocket(SocketImpl impl) {       this.impl = impl;       impl.setServerSocket(this); // <- NPE if impl

Re: RFR [12] 8213296: Fix legal headers in test/jdk/java/net

On 02/11/2018 14:36, Chris Hegarty wrote: Following Jon’s lead in the langtools area, here is a change to remove the "Classpath exception” from several test in the networking area. http://cr.openjdk.java.net/~chegar/8213296/webrev/ Looks okay. -Alan

Re: RFR [12] 8210493: Bind to node- or linklocal ipv6 multicast address fails

On 07/11/2018 14:12, Pavel Rappo wrote: Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8210493/webrev.00 This change fixes binding to interface-local and link-local IPv6 multicast addresses on Linux. Does the comment at L806 need to be updated? Also the change

Re: RFR [12] 8210493: Bind to node- or linklocal ipv6 multicast address fails

On 07/11/2018 16:23, Pavel Rappo wrote: On 7 Nov 2018, at 15:22, Alan Bateman wrote: Does the comment at L806 need to be updated? Also the change makes me wondering about the 2.4 kernel support, maybe it is time to think about dropping some of the older code path. Alan, Is that better

Re: RFR [12] 8213418: Socket/ServerSocket supportedOptions does not work with custom SocketImpl

On 07/11/2018 15:16, Chris Hegarty wrote: Socket and ServerSocket supportedOptions() caches the supported options in a static field on the assumption that all implementations support the same set of options. This assumption is incorrect. The cache can be on a per-socket basis ( which has been im

Re: RFR [12] 8213418: Socket/ServerSocket supportedOptions does not work with custom SocketImpl

On 08/11/2018 13:03, Chris Hegarty wrote: On 08/11/18 11:53, Chris Hegarty wrote: ... Received some offline comments about the use of VarHandle. Removed the superfluous use of VarHandle, we now implicitly trust the socket impl ( even more ). http://cr.openjdk.java.net/~chegar/8213418/webr

Re: RFR [12] 8213490: Networking area nano cleanup

On 12/11/2018 17:30, Daniel Fuchs wrote: Hi Pavel, The typos fixes look OK to me - I'll let Michael/Chris? who have more knowledge on the history of the Inet6Address impl to validate the new link - though I suspect that's OK. It will need a CSR because it changes Inet6Address to specify that

Re: RFR [12] 8213490: Networking area nano cleanup

On 12/11/2018 23:51, Pavel Rappo wrote: Daniel, Alan, I excluded the update from the draft to the RFC and created a separate bug for it: [P5] 8213757: Investigate the possibility of updating the reference to the spec in java.net.Inet6Address I added the changes to the URI class from JDK-

Re: RFR: 8213942:URLStreamHandler initialization race

On 20/11/2018 17:55, Seán Coffey wrote: A race condition recently reported by the WLS team. Access to the handlers Hashtable and the factory should be made while holding the streamHandlerLock lock. WLS team also made efforts to create a reproducer. I've modified to jtreg format and reduced it

Re: RFR: 8213942:URLStreamHandler initialization race

On 21/11/2018 13:04, Seán Coffey wrote: Thanks to all for the feedback. It makes sense to reduce the scope of the lock where possible. I've updated the webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213942.v2/webrev/ Looks good to me too. -Alan

Re: RFR 8214014 : Remove vestiges of gopher: protocol proxy support

On 28/11/2018 16:34, Roger Riggs wrote: Please review the removal of some left over references to the gopher protocol related to proxies. Most are related to properties or setting up proxies (for gopher). Please check in javax.print that the inclusion of the gopher protocol is no longer nee

Re: RFR: 8211842 IPv6_supported wrongly returns false when unix domain socket is bound to fd 0

On 28/11/2018 15:50, Michael McMahon wrote: Could I get the following fix reviewed please? The fix is pretty simple, but the test a bit more involved since the issue occurs when the JVM is launched in unusual circumstances where its stdin,out,err are connected to a UNIX domain socket. This occurs

Re: 8211842 IPv6_supported wrongly returns false when unix domainsocket is bound to fd 0

On 29/11/2018 18:04, Bernd Eckenfels wrote: Hello, I wonder if that conclusion „stdin = tcp4 -> disable tcp6“ is correct at all. The started program might serve a v4 connection but it still could want to do ipv6 client connections. If somebody wants to disable v4 they can do it regularly wi

Re: 8211842 IPv6_supported wrongly returns false when unix domainsocket is bound to fd 0

On 29/11/2018 20:29, Michael McMahon wrote: : I've updated the webrev after the last comments: http://cr.openjdk.java.net/~michaelm/8211842/webrev.2/ It's really just refactoring. So, unless anyone has a comment I will push the fix shortly. Thanks for the update, this version looks good to me

Re: RFR 8215008: Clear confusion between URL/URI paths and file system paths

On 07/12/2018 15:13, Daniel Fuchs wrote: Hi, Please find below a fix for 8215008: Clear confusion between URL/URI paths and file system paths https://bugs.openjdk.java.net/browse/JDK-8215008 It adds a small non normative @apiNote to java.net.URL and java.net.URI. http://cr.openjdk.java.net/~df

Re: RFR 8215008: Clear confusion between URL/URI paths and file system paths

On 10/12/2018 17:54, Daniel Fuchs wrote: Hi Alan, Here is an updated webrev that takes into account your later feedback: http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.02/ This update looks good to me. -Alan

Re: RFR [12] 8215292: Back out changes for node- and link- local ipv6 multicast address

On 12/12/2018 16:15, Chris Hegarty wrote: The backout looks correct, and I agree with the approach. -Chris. On 12/12/2018 16:09, Pavel Rappo wrote: Hello, Please review the following change:   http://cr.openjdk.java.net/~prappo/8215292/webrev.00 That change backs out the fix for "Bind to

Re: RFR: 8215281: Use String.isEmpty() where applicable in java.base

On 12/12/2018 16:53, Claes Redestad wrote: Hi, please review this patch to use String.isEmpty when applicable: Webrev: http://cr.openjdk.java.net/~redestad/8215281/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215281 Why? - It reads better :-) - Better startup/warmup due fewer method

Re: RFR: 8215990: Avoid using reflection to create common default URLStreamHandlers

On 02/01/2019 09:02, Claes Redestad wrote: Hi, during bootstrap we load and use at least two of the jrt, file and jar URLStreamHandlers via URL$DefaultFactory. Avoiding use of reflection to instantiate these slightly speed up bootstrap by reducing number of classes loaded and doing fewer relativ

Re: RFR: 8215990: Avoid using reflection to create common default URLStreamHandlers

On 02/01/2019 10:43, Claes Redestad wrote: : While we're in the area then it would be nice to eliminate the use of Class::newInstance too - if each of the built-in protocol handlers is public with a public no-arg constructor then getConstructor().newInstance() should do it. To be perfectl

Re: RFR(XS): 8217311: Improve Exception thrown when MulticastSocket.setInterface fails on AIX(Unix)

Looks okay to me too.  I think we should encourage new multicast applications to move to DatagramChannel as it a defines factory methods to specify the protocol family at creation time. Also setOption(IP_MULTICAST_IF, ...) and the join methods are also specified for such cases. Going forward I

8217451: ExtendedSocketOptions should encapsulate support for SO_FLOW_SLA

ExtendSocketOptions is the supporting class that the socket implementations use for JDK-specific socket options. Vyom improved it last year to select options based on the socket type but more is needed to handle socket options that are specific to connecting or listening sockets. As things stan

8217461: (ch) Add Net.available to return the number of bytes in the socket input buffer

This is a small change to add a method to sun.nio.ch.Net to get the number of bytes in the socket input buffer. The motive for adding this to make it possible for the socket adaptors to implement InputStream::available and also to support an alternative SocketImpl based on NIO. I've used the op

Re: 8217451: ExtendedSocketOptions should encapsulate support for SO_FLOW_SLA

On 21/01/2019 18:00, Michael McMahon wrote: Hi Alan, Looks fine apart from extra space on line 85: ExtendedSocketOptions.java Thanks, I'll fix that before pushing. -Alan

Re: 8217461: (ch) Add Net.available to return the number of bytes in the socket input buffer

On 22/01/2019 08:07, Langer, Christoph wrote: Hi Alan, the change looks good to me. In src/java.base/unix/native/libnio/ch/Net.c and src/java.base/windows/native/libnio/ch/Net.c you could change the code from ... int n = NET_SocketAvailable(fdval(env, fdo), &count); if (n != 0) { ... to o

Re: 8217461: (ch) Add Net.available to return the number of bytes in the socket input buffer

On 23/01/2019 09:42, Florian Weimer wrote: : Do you plan to read from the socket buffer in the implementation of available()? The problem is that even if there is currently data in the socket buffer, further data that arrives later can clear it. I think this can only happen as part of a connect

<    1   2   3   4   5   6   7   8   9   10   >