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: 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: 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: 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: 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 [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 [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] 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] 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] 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] 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] 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: 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: 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: 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: 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 [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 [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 : 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] 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: [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: [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 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 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 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: [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: [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 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 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 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

/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 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: [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: 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: 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: 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: 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: 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: 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: 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 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 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

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

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 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 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 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 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: 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: 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: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: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 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: 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 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: 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 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 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 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 [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 [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 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] 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 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 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 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 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 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 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

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

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

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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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 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: 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: Per-Connection TCP keepalive parameters and application-wide keepalive enforcement.

On 10/11/2017 06:09, Bernd Eckenfels wrote: Hello, TCP keepalive is a rather elegant mechanism to detect abandoned TCP Connections. With increased distribution of components and inclusion of Cloud based services I have the feeling it has become more important. Yet it is rather clumsy to use

Re: RFR 8145635 : Add TCP_QUICKACK socket option

On 19/10/2017 03:56, vyom tewari wrote: Hi All, please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.7/index.html). I can't recall if I brought this up already but we do have an issue to deprecate-for-removal jdk.net.Sockets? Socket and friends were rev'ed in Ja

Re: RFR 8145635 : Add TCP_QUICKACK socket option

On 11/10/2017 21:08, Chris Hegarty wrote: Given that this option is specific to TCP, then the `TCP_` prefix is more appropriate. I agree. We have StandardSocketOptions.TCP_NODELAY as an example to look at. -Alan

Re: [10] RFR: 8186930: Constant fold URI constants

On 31/08/2017 16:26, Claes Redestad wrote: On 2017-08-30 17:17, Alan Bateman wrote: I think it could be useful as someone reading the code isn't going to immediately know to jump to URI. Done: http://cr.openjdk.java.net/~redestad/8186930/jdk.01/ This looks good to me. -Alan

Re: [10] RFR: 8186930: Constant fold URI constants

On 31/08/2017 00:11, Claes Redestad wrote: : I just wonder if ParseUtil should keep the lowMask/highMask methods in comments so that further maintainers can satisfy themselves that the values are correct. I thought leaving a comment in ParseUtil that they can be still found in URI was suf

Re: [10] RFR: 8186930: Constant fold URI constants

On 29/08/2017 21:26, Claes Redestad wrote: Hi, please review this patch to pre-calculate constants in java.net.URI and sun.net.www.ParseUtil, removing work from runtime (reduces bytecodes executed in the interpreter on bootstrap by ~15K). This also removes use of BitSet from ParseUtil, which ap

Re: Expose DNS Servers via public API

On 30/03/2017 15:59, Norman Maurer wrote: Thats why I tried to kick-off the topic :) Thanks for the quick reply btw…. So is this list the right place for this discussion ? I just checked the docs for the JNDI-DNS provider [1] and it documents that the provider updates the java.naming.provider

Re: Expose DNS Servers via public API

On 30/03/2017 15:36, Norman Maurer wrote: Hi there, I am not sure if this is the correct list for the question but as relate to network I will just try. If its the wrong list please tell me which one would be better fitted. Is there reason why not expose the DNS Servers configured on a syst

Re: Let's improve IPv6 support

On 17/03/2017 18:47, Martin Buchholz wrote: Google cares a lot about IPv6, and not only because Vint Cerf works at Google. We have some local modifications and some networking expertise and intend to port/contribute that to openjdk10. Most of this is the work of my colleagues Alexander Smun

Re: RFR: JDK-8174716,,java/net/httpclient/security/Driver.java failing in JDK 9

Looks okay. On 10/02/2017 09:35, Michael McMahon wrote: This test has been failing since the introduction of the incubator mechanism but wasn't being run due to an issue with jtreg that is about to be fixed. This fixes the problem with the test first. http://cr.openjdk.java.net/~michaelm/81

Re: RFR: 8167178 Exported elements referring to inaccessible types in java.naming

On 16/01/2017 09:10, Vyom Tewari wrote: Hi All, Please review below the small fix for the issue. BugId : https://bugs.openjdk.java.net/browse/JDK-8167178 The compatibility impact is minimum as no code in JDK is currently depend on it. I think this is okay, it is technically an API change bu

Re: RFR: JDK-8164815 - 3 JCK NetworkInterface tests fail on Raspberry Pi

On 10/11/2016 20:26, Chris Hegarty wrote: : It has, but, for me at least, since the changes for 7120665 [1] require a conformant implementation to support at least one network interface, it seems more like an error if we encounter this situation. Ugh, I'd forgotten that needs to be supported t

Re: RFR: JDK-8164815 - 3 JCK NetworkInterface tests fail on Raspberry Pi

On 10/11/2016 16:39, Mark Sheppard wrote: Hi, please oblige and review the change http://cr.openjdk.java.net/~msheppar/8164815/webrev/src/java.base/share/classes/java/net/NetworkInterface.java.sdiff.html to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8164815 It w

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