From sbaiduzh at redhat.com Mon May 4 15:38:46 2015 From: sbaiduzh at redhat.com (Stanislav Baiduzhyi) Date: Mon, 04 May 2015 17:38:46 +0200 Subject: DNS resolution fails after resolv.conf update Message-ID: <18346099.VQWo4FIar9@thinkpad.hell> Hi All, We are facing an issue with DNS server caching on RHEL-based distros: after the update of resolv.conf java application cannot resolve the hosts any more. Reproducer is very simple: 1. Clean /etc/resolv.conf or connect to vpn and use vpn-only nameserver. 2. Launch the minimal java app [1]. 3. Restore the /etc/resolv.conf or disconnect from vpn (/etc/resolv.conf should be updated with accessible nameserver at this moment). 4. Notice that name resolution continues to fail. I've prepared a small webrev that fixes the issue [2], but would like to hear some ideas/criticism first. If the patch looks ok to everyone, please create an issue for this, and I will submit it for approval/sponsorship. [1]: https://e61b615da46327c9050d624b0a3783ba21c6b125.googledrive.com/host/0B5Kp-cB1sXJrfnZ4NHZ0S1V3UTJZcDFra3RwUFZjQXY5WVZzUkwtTTd0Z1IyR1JmbDZPSVk/resolvconf-reinit/ResolvingHost.java [2]: https://e61b615da46327c9050d624b0a3783ba21c6b125.googledrive.com/host/0B5Kp-cB1sXJrfnZ4NHZ0S1V3UTJZcDFra3RwUFZjQXY5WVZzUkwtTTd0Z1IyR1JmbDZPSVk/resolvconf-reinit/ -- Regards, Stas From kubota.yuji at gmail.com Mon May 4 16:19:54 2015 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Tue, 5 May 2015 01:19:54 +0900 Subject: Potential infinite waiting at JMXConnection#createConnection In-Reply-To: References: Message-ID: Hi all, I want to contribute this issue. If there are a problem about this patch or a better way for openjdk community, please advise me. Thanks for 2015-04-22 0:31 GMT+09:00 KUBOTA Yuji : > Hi all, > > I found an infinite waiting at TCPChannel#createConnection. > This method flushes the DataOutputStream without the socket timeout settings > when choose stream protocol [1]. > > If connection lost (the destination server do no return response) > during the flush, > this method has possibilities to take long time beyond the expectations > at java.net.SocketInputStream.socketRead0 as following stack trace. > > stack trace : > at java.net.SocketInputStream.socketRead0(SocketInputStream.java) > at java.net.SocketInputStream.read(SocketInputStream.java) > at java.net.SocketInputStream.read(SocketInputStream.java) > at sun.security.ssl.InputRecord.readFully(InputRecord.java) > at sun.security.ssl.InputRecord.read(InputRecord.java) > at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java) > at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java) > at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java) > at sun.security.ssl.AppOutputStream.write(AppOutputStream.java) > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java) > at java.io.DataOutputStream.flush(DataOutputStream.java) > at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java) > at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java) > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java) > at javax.management.remote.rmi.RMIServerImpl_Stub.newClient > at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java) > at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java) > at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java) > > When create connection, we cannot set the timeout by properties. > Therefore, JMX sets the default value of SO_TIMEOUT, i.e., infinite. > So I wrote a patch to fix this infinite waiting by using property-configured value: > sun.rmi.transport.tcp.responseTimeout. > > Please review this patch. :) > > Note: My OCA has been processed a few hour ago, so my name may take a > short time to > appear on the OCA signatories page. > > Thanks, > KUBOTA Yuji > > [1]: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java#l191 > > diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > --- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > +++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > @@ -222,20 +222,34 @@ > // choose protocol (single op if not reusable socket) > if (!conn.isReusable()) { > out.writeByte(TransportConstants.SingleOpProtocol); > } else { > out.writeByte(TransportConstants.StreamProtocol); > + > + int usableSoTimeout = 0; > + try { > + /* > + * If socket factory had set a zero timeout on its own, > + * then set the property-configured value to prevent > + * an infinite waiting. > + */ > + usableSoTimeout = sock.getSoTimeout(); > + if (usableSoTimeout == 0) { > + usableSoTimeout = responseTimeout; > + } > + sock.setSoTimeout(usableSoTimeout); > + } catch (Exception e) { > + // if we fail to set this, ignore and proceed anyway > + } > out.flush(); > > /* > * Set socket read timeout to configured value for JRMP > * connection handshake; this also serves to guard against > * non-JRMP servers that do not respond (see 4322806). > */ > - int originalSoTimeout = 0; > try { > - originalSoTimeout = sock.getSoTimeout(); > sock.setSoTimeout(handshakeTimeout); > } catch (Exception e) { > // if we fail to set this, ignore and proceed anyway > } > > @@ -279,18 +293,11 @@ > * connection. NOTE: this timeout, if configured to a > * finite duration, places an upper bound on the time > * that a remote method call is permitted to execute. > */ > try { > - /* > - * If socket factory had set a non-zero timeout on its > - * own, then restore it instead of using the property- > - * configured value. > - */ > - sock.setSoTimeout((originalSoTimeout != 0 ? > - originalSoTimeout : > - responseTimeout)); > + sock.setSoTimeout(usableSoTimeout); > } catch (Exception e) { > // if we fail to set this, ignore and proceed anyway > } > > out.flush(); From benjamin.john.evans at gmail.com Mon May 4 17:22:04 2015 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Mon, 4 May 2015 18:22:04 +0100 Subject: Potential infinite waiting at JMXConnection#createConnection In-Reply-To: References: Message-ID: Hi Kubota, I think that perhaps the AdoptOpenJDK project (https://java.net/projects/adoptopenjdk) can help here. I've copied in their mailing list, in case one of the developers there can help you. Thanks, Ben On Mon, May 4, 2015 at 5:19 PM, KUBOTA Yuji wrote: > Hi all, > > I want to contribute this issue. > If there are a problem about this patch or a better way for openjdk > community, please advise me. > > Thanks for > > 2015-04-22 0:31 GMT+09:00 KUBOTA Yuji : >> Hi all, >> >> I found an infinite waiting at TCPChannel#createConnection. >> This method flushes the DataOutputStream without the socket timeout settings >> when choose stream protocol [1]. >> >> If connection lost (the destination server do no return response) >> during the flush, >> this method has possibilities to take long time beyond the expectations >> at java.net.SocketInputStream.socketRead0 as following stack trace. >> >> stack trace : >> at java.net.SocketInputStream.socketRead0(SocketInputStream.java) >> at java.net.SocketInputStream.read(SocketInputStream.java) >> at java.net.SocketInputStream.read(SocketInputStream.java) >> at sun.security.ssl.InputRecord.readFully(InputRecord.java) >> at sun.security.ssl.InputRecord.read(InputRecord.java) >> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java) >> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java) >> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java) >> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java) >> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java) >> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java) >> at java.io.DataOutputStream.flush(DataOutputStream.java) >> at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java) >> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java) >> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java) >> at javax.management.remote.rmi.RMIServerImpl_Stub.newClient >> at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java) >> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java) >> at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java) >> >> When create connection, we cannot set the timeout by properties. >> Therefore, JMX sets the default value of SO_TIMEOUT, i.e., infinite. >> So I wrote a patch to fix this infinite waiting by using property-configured value: >> sun.rmi.transport.tcp.responseTimeout. >> >> Please review this patch. :) >> >> Note: My OCA has been processed a few hour ago, so my name may take a >> short time to >> appear on the OCA signatories page. >> >> Thanks, >> KUBOTA Yuji >> >> [1]: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java#l191 >> >> diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >> b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >> --- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >> +++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >> @@ -222,20 +222,34 @@ >> // choose protocol (single op if not reusable socket) >> if (!conn.isReusable()) { >> out.writeByte(TransportConstants.SingleOpProtocol); >> } else { >> out.writeByte(TransportConstants.StreamProtocol); >> + >> + int usableSoTimeout = 0; >> + try { >> + /* >> + * If socket factory had set a zero timeout on its own, >> + * then set the property-configured value to prevent >> + * an infinite waiting. >> + */ >> + usableSoTimeout = sock.getSoTimeout(); >> + if (usableSoTimeout == 0) { >> + usableSoTimeout = responseTimeout; >> + } >> + sock.setSoTimeout(usableSoTimeout); >> + } catch (Exception e) { >> + // if we fail to set this, ignore and proceed anyway >> + } >> out.flush(); >> >> /* >> * Set socket read timeout to configured value for JRMP >> * connection handshake; this also serves to guard against >> * non-JRMP servers that do not respond (see 4322806). >> */ >> - int originalSoTimeout = 0; >> try { >> - originalSoTimeout = sock.getSoTimeout(); >> sock.setSoTimeout(handshakeTimeout); >> } catch (Exception e) { >> // if we fail to set this, ignore and proceed anyway >> } >> >> @@ -279,18 +293,11 @@ >> * connection. NOTE: this timeout, if configured to a >> * finite duration, places an upper bound on the time >> * that a remote method call is permitted to execute. >> */ >> try { >> - /* >> - * If socket factory had set a non-zero timeout on its >> - * own, then restore it instead of using the property- >> - * configured value. >> - */ >> - sock.setSoTimeout((originalSoTimeout != 0 ? >> - originalSoTimeout : >> - responseTimeout)); >> + sock.setSoTimeout(usableSoTimeout); >> } catch (Exception e) { >> // if we fail to set this, ignore and proceed anyway >> } >> >> out.flush(); From kubota.yuji at gmail.com Mon May 4 18:55:25 2015 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Tue, 5 May 2015 03:55:25 +0900 Subject: Potential infinite waiting at JMXConnection#createConnection In-Reply-To: References: Message-ID: Hi all, My apologies for the re-post and wrong link, the link [1] of the initial post is not correctly. The correct link is below. [1]: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l227 The users cant specify the timeout by sun.rmi.transport.tcp.responseTimeout, e.g. the second flush() of TCPChannel#createConnection [2]. However, the first flush() [1] is not affected by sun.rmi.transport.tcp.responseTimeout, and will be the (potential) infinite waiting by bad luck. [2]: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l296 Thanks, Yuji 2015-05-05 1:19 GMT+09:00 KUBOTA Yuji : > Hi all, > > I want to contribute this issue. > If there are a problem about this patch or a better way for openjdk > community, please advise me. > > Thanks for > > 2015-04-22 0:31 GMT+09:00 KUBOTA Yuji : >> Hi all, >> >> I found an infinite waiting at TCPChannel#createConnection. >> This method flushes the DataOutputStream without the socket timeout settings >> when choose stream protocol [1]. >> >> If connection lost (the destination server do no return response) >> during the flush, >> this method has possibilities to take long time beyond the expectations >> at java.net.SocketInputStream.socketRead0 as following stack trace. >> >> stack trace : >> at java.net.SocketInputStream.socketRead0(SocketInputStream.java) >> at java.net.SocketInputStream.read(SocketInputStream.java) >> at java.net.SocketInputStream.read(SocketInputStream.java) >> at sun.security.ssl.InputRecord.readFully(InputRecord.java) >> at sun.security.ssl.InputRecord.read(InputRecord.java) >> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java) >> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java) >> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java) >> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java) >> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java) >> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java) >> at java.io.DataOutputStream.flush(DataOutputStream.java) >> at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java) >> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java) >> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java) >> at javax.management.remote.rmi.RMIServerImpl_Stub.newClient >> at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java) >> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java) >> at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java) >> >> When create connection, we cannot set the timeout by properties. >> Therefore, JMX sets the default value of SO_TIMEOUT, i.e., infinite. >> So I wrote a patch to fix this infinite waiting by using property-configured value: >> sun.rmi.transport.tcp.responseTimeout. >> >> Please review this patch. :) >> >> Note: My OCA has been processed a few hour ago, so my name may take a >> short time to >> appear on the OCA signatories page. >> >> Thanks, >> KUBOTA Yuji >> >> [1]: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java#l191 >> >> diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >> b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >> --- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >> +++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >> @@ -222,20 +222,34 @@ >> // choose protocol (single op if not reusable socket) >> if (!conn.isReusable()) { >> out.writeByte(TransportConstants.SingleOpProtocol); >> } else { >> out.writeByte(TransportConstants.StreamProtocol); >> + >> + int usableSoTimeout = 0; >> + try { >> + /* >> + * If socket factory had set a zero timeout on its own, >> + * then set the property-configured value to prevent >> + * an infinite waiting. >> + */ >> + usableSoTimeout = sock.getSoTimeout(); >> + if (usableSoTimeout == 0) { >> + usableSoTimeout = responseTimeout; >> + } >> + sock.setSoTimeout(usableSoTimeout); >> + } catch (Exception e) { >> + // if we fail to set this, ignore and proceed anyway >> + } >> out.flush(); >> >> /* >> * Set socket read timeout to configured value for JRMP >> * connection handshake; this also serves to guard against >> * non-JRMP servers that do not respond (see 4322806). >> */ >> - int originalSoTimeout = 0; >> try { >> - originalSoTimeout = sock.getSoTimeout(); >> sock.setSoTimeout(handshakeTimeout); >> } catch (Exception e) { >> // if we fail to set this, ignore and proceed anyway >> } >> >> @@ -279,18 +293,11 @@ >> * connection. NOTE: this timeout, if configured to a >> * finite duration, places an upper bound on the time >> * that a remote method call is permitted to execute. >> */ >> try { >> - /* >> - * If socket factory had set a non-zero timeout on its >> - * own, then restore it instead of using the property- >> - * configured value. >> - */ >> - sock.setSoTimeout((originalSoTimeout != 0 ? >> - originalSoTimeout : >> - responseTimeout)); >> + sock.setSoTimeout(usableSoTimeout); >> } catch (Exception e) { >> // if we fail to set this, ignore and proceed anyway >> } >> >> out.flush(); From ecki at zusammenkunft.net Mon May 4 20:26:26 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 4 May 2015 22:26:26 +0200 Subject: DNS resolution fails after resolv.conf update In-Reply-To: <18346099.VQWo4FIar9@thinkpad.hell> References: <18346099.VQWo4FIar9@thinkpad.hell> Message-ID: <20150504222626.00000d17.ecki@zusammenkunft.net> Hello, not sure how I feel about the res_init(). Depending on the backends used this might be expensive. Especially since it wont be rate limited. The negative-ttl of 10s is for single records I thing. So at a minimum you should rate-limit res_init to the same negative-ttl time). But another aspect: this is also a problem for positive answers. Only because you get an answer does not mean it is the NS you wanted to query. Maybe a background refreshing could solve both? Would also reduce concurrency. debian/ubuntu BTW seems to have a rather elaborate reload hook mechanism: http://manpages.ubuntu.com/manpages/gutsy/man8/resolvconf.8.html But that is I guess hard to integrate with JVM. Gruss Bernd Am Mon, 04 May 2015 17:38:46 +0200 schrieb Stanislav Baiduzhyi : > Hi All, > > We are facing an issue with DNS server caching on RHEL-based distros: > after the update of resolv.conf java application cannot resolve the > hosts any more. > > Reproducer is very simple: > 1. Clean /etc/resolv.conf or connect to vpn and use vpn-only > nameserver. 2. Launch the minimal java app [1]. > 3. Restore the /etc/resolv.conf or disconnect from vpn > (/etc/resolv.conf should be updated with accessible nameserver at > this moment). 4. Notice that name resolution continues to fail. > > I've prepared a small webrev that fixes the issue [2], but would like > to hear some ideas/criticism first. If the patch looks ok to > everyone, please create an issue for this, and I will submit it for > approval/sponsorship. > > [1]: > https://e61b615da46327c9050d624b0a3783ba21c6b125.googledrive.com/host/0B5Kp-cB1sXJrfnZ4NHZ0S1V3UTJZcDFra3RwUFZjQXY5WVZzUkwtTTd0Z1IyR1JmbDZPSVk/resolvconf-reinit/ResolvingHost.java > > [2]: > https://e61b615da46327c9050d624b0a3783ba21c6b125.googledrive.com/host/0B5Kp-cB1sXJrfnZ4NHZ0S1V3UTJZcDFra3RwUFZjQXY5WVZzUkwtTTd0Z1IyR1JmbDZPSVk/resolvconf-reinit/ > From christos at zoulas.com Tue May 5 01:16:40 2015 From: christos at zoulas.com (Christos Zoulas) Date: Mon, 4 May 2015 21:16:40 -0400 Subject: DNS resolution fails after resolv.conf update In-Reply-To: <18346099.VQWo4FIar9@thinkpad.hell> from Stanislav Baiduzhyi (May 4, 5:38pm) Message-ID: <20150505011640.3BB5317FDA8@rebar.astron.com> On May 4, 5:38pm, sbaiduzh at redhat.com (Stanislav Baiduzhyi) wrote: -- Subject: DNS resolution fails after resolv.conf update | Hi All, | | We are facing an issue with DNS server caching on RHEL-based distros: after | the update of resolv.conf java application cannot resolve the hosts any more. | | Reproducer is very simple: | 1. Clean /etc/resolv.conf or connect to vpn and use vpn-only nameserver. | 2. Launch the minimal java app [1]. | 3. Restore the /etc/resolv.conf or disconnect from vpn (/etc/resolv.conf | should be updated with accessible nameserver at this moment). | 4. Notice that name resolution continues to fail. | | I've prepared a small webrev that fixes the issue [2], but would like to hear | some ideas/criticism first. If the patch looks ok to everyone, please create | an issue for this, and I will submit it for approval/sponsorship. | | [1]: | https://e61b615da46327c9050d624b0a3783ba21c6b125.googledrive.com/host/0B5Kp-cB1sXJrfnZ4NHZ0S1V3UTJZcDFra3RwUFZjQXY5WVZzUkwtTTd0Z1IyR1JmbDZPSVk/resolvconf-reinit/ResolvingHost.java | | [2]: | https://e61b615da46327c9050d624b0a3783ba21c6b125.googledrive.com/host/0B5Kp-cB1sXJrfnZ4NHZ0S1V3UTJZcDFra3RwUFZjQXY5WVZzUkwtTTd0Z1IyR1JmbDZPSVk/resolvconf-reinit/ I don't think it is the job of the JDK to handle this. For example many systems (like NetBSD for example) work just fine without needing this, because their libc keeps track of resolv.conf changes. On other systems, calling res_init() does not even work properly because the getaddrinfo() call uses the re-entrant API to be thread safe (res_ninit()/res_nsend() etc.). Additionally res_init() isn't even thread-safe (on most implementations), so multiple threads calling it at the same time can corrupt the resolver state. Fixing it the way you propose means that every application that does hostname/address resolution would need to be modified in order to work. christos From sbaiduzh at redhat.com Tue May 5 11:32:40 2015 From: sbaiduzh at redhat.com (Stanislav Baiduzhyi) Date: Tue, 05 May 2015 13:32:40 +0200 Subject: DNS resolution fails after resolv.conf update In-Reply-To: <20150504222626.00000d17.ecki@zusammenkunft.net> References: <18346099.VQWo4FIar9@thinkpad.hell> <20150504222626.00000d17.ecki@zusammenkunft.net> Message-ID: <33278130.aqaELziWkd@thinkpad.hell> On Monday 04 May 2015 22:26:26 Bernd Eckenfels wrote: > not sure how I feel about the res_init(). Depending on the backends > used this might be expensive. Especially since it wont be rate > limited. The negative-ttl of 10s is for single records I thing. So at a > minimum you should rate-limit res_init to the same negative-ttl time). > > But another aspect: this is also a problem for positive answers. Only > because you get an answer does not mean it is the NS you wanted to > query. Maybe a background refreshing could solve both? Would also > reduce concurrency. > > debian/ubuntu BTW seems to have a rather elaborate reload hook > mechanism: > http://manpages.ubuntu.com/manpages/gutsy/man8/resolvconf.8.html > > > But that is I guess hard to integrate with JVM. Bernd, I like the idea with background thread. I'll dig into it to see what other threads are there, maybe there is already something similar that can extend its purpose. or will try to create additional thread for that. -- Regards, Stas From sbaiduzh at redhat.com Tue May 5 11:32:56 2015 From: sbaiduzh at redhat.com (Stanislav Baiduzhyi) Date: Tue, 05 May 2015 13:32:56 +0200 Subject: DNS resolution fails after resolv.conf update In-Reply-To: <20150505011640.3BB5317FDA8@rebar.astron.com> References: <20150505011640.3BB5317FDA8@rebar.astron.com> Message-ID: <9116655.V9BhPaDOkX@thinkpad.hell> Hi Christos, On Monday 04 May 2015 21:16:40 Christos Zoulas wrote: > I don't think it is the job of the JDK to handle this. For example > many systems (like NetBSD for example) work just fine without > needing this, because their libc keeps track of resolv.conf changes. Normally I would agree with you, but if the OS does not provide that functionality for any reason we still have to provide working solution from java perspective. > On other systems, calling res_init() does not even work properly > because the getaddrinfo() call uses the re-entrant API to be thread > safe (res_ninit()/res_nsend() etc.). > > Additionally res_init() isn't even thread-safe (on most implementations), > so multiple threads calling it at the same time can corrupt the > resolver state. > > Fixing it the way you propose means that every application that > does hostname/address resolution would need to be modified in order > to work. Good point. I see that some patches to glibc to handle this issue are using lock mechanism, plus Bernd suggested to use a separate thread for this. I'll try implementing both of those variants and will return with another webrev. -- Regards, Stas From christos at zoulas.com Tue May 5 12:38:12 2015 From: christos at zoulas.com (Christos Zoulas) Date: Tue, 5 May 2015 08:38:12 -0400 Subject: DNS resolution fails after resolv.conf update In-Reply-To: <9116655.V9BhPaDOkX@thinkpad.hell> from Stanislav Baiduzhyi (May 5, 1:32pm) Message-ID: <20150505123812.148B317FDA8@rebar.astron.com> On May 5, 1:32pm, sbaiduzh at redhat.com (Stanislav Baiduzhyi) wrote: -- Subject: Re: DNS resolution fails after resolv.conf update | Hi Christos, | | On Monday 04 May 2015 21:16:40 Christos Zoulas wrote: | > I don't think it is the job of the JDK to handle this. For example | > many systems (like NetBSD for example) work just fine without | > needing this, because their libc keeps track of resolv.conf changes. | | Normally I would agree with you, but if the OS does not provide that | functionality for any reason we still have to provide working solution from | java perspective. I still maintain that it is the wrong place to fix this. The proof to this will be the difficulty you'll have providing a portable solution that works across a variety of OS's. Fixing it for linux and glibc is not very hard, but you'll need to limit your solution to that in order not to break other OS's. | > On other systems, calling res_init() does not even work properly | > because the getaddrinfo() call uses the re-entrant API to be thread | > safe (res_ninit()/res_nsend() etc.). | > | > Additionally res_init() isn't even thread-safe (on most implementations), | > so multiple threads calling it at the same time can corrupt the | > resolver state. | > | > Fixing it the way you propose means that every application that | > does hostname/address resolution would need to be modified in order | > to work. | | Good point. I see that some patches to glibc to handle this issue are using | lock mechanism, plus Bernd suggested to use a separate thread for this. I'll | try implementing both of those variants and will return with another webrev. Well, even if you are going to call res_init() periodically, you will still have to contend with two races: - calling getaddrinfo() from another thread while res_init() is being called, will possibly access a partially inited _res (If your implementation's getaddrinfo() is using _res that is). - calling getaddrinfo() immediately after resolv.conf is updated and before res_init() is called (will fail to find new hosts -- the problem you are trying to solve). It is 2015, not the 80's anymore where it was acceptable to restart programs to have them re-read configuration files. Libc API's such as getaddrinfo() need to be robust. It does not cost that much after all to do a stat() to see if resolv.conf changed in libc as opposed to having a thread in java baby-sitting it. christos From fweimer at redhat.com Fri May 15 20:41:27 2015 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 15 May 2015 22:41:27 +0200 Subject: DNS resolution fails after resolv.conf update In-Reply-To: <18346099.VQWo4FIar9@thinkpad.hell> References: <18346099.VQWo4FIar9@thinkpad.hell> Message-ID: <555659F7.70203@redhat.com> On 05/04/2015 05:38 PM, Stanislav Baiduzhyi wrote: > We are facing an issue with DNS server caching on RHEL-based distros: after > the update of resolv.conf java application cannot resolve the hosts any more. > > Reproducer is very simple: > 1. Clean /etc/resolv.conf or connect to vpn and use vpn-only nameserver. > 2. Launch the minimal java app [1]. > 3. Restore the /etc/resolv.conf or disconnect from vpn (/etc/resolv.conf > should be updated with accessible nameserver at this moment). > 4. Notice that name resolution continues to fail. This is a glibc bug: (I don't agree with the decision not to fix this, but I hesitate to touch the glibc resolver code, particularly in this area.) nscd doesn't work reliable for this use case, a further fix is needed: (Also see rhbz#859965, currently not public.) Would using nscd work for you? -- Florian Weimer / Red Hat Product Security From dmitry.samersoff at oracle.com Fri May 15 21:39:45 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 16 May 2015 00:39:45 +0300 Subject: DNS resolution fails after resolv.conf update In-Reply-To: <18346099.VQWo4FIar9@thinkpad.hell> References: <18346099.VQWo4FIar9@thinkpad.hell> Message-ID: <555667A1.5080903@oracle.com> Stanislav, I don't think we should fix it on JDK level. Workaround is obvious and actually recommended for production - install one of cashing nameservers and lock resolv.conf to localhost. -Dmitry On 2015-05-04 18:38, Stanislav Baiduzhyi wrote: > Hi All, > > We are facing an issue with DNS server caching on RHEL-based distros: after > the update of resolv.conf java application cannot resolve the hosts any more. > > Reproducer is very simple: > 1. Clean /etc/resolv.conf or connect to vpn and use vpn-only nameserver. > 2. Launch the minimal java app [1]. > 3. Restore the /etc/resolv.conf or disconnect from vpn (/etc/resolv.conf > should be updated with accessible nameserver at this moment). > 4. Notice that name resolution continues to fail. > > I've prepared a small webrev that fixes the issue [2], but would like to hear > some ideas/criticism first. If the patch looks ok to everyone, please create > an issue for this, and I will submit it for approval/sponsorship. > > [1]: > https://e61b615da46327c9050d624b0a3783ba21c6b125.googledrive.com/host/0B5Kp-cB1sXJrfnZ4NHZ0S1V3UTJZcDFra3RwUFZjQXY5WVZzUkwtTTd0Z1IyR1JmbDZPSVk/resolvconf-reinit/ResolvingHost.java > > [2]: > https://e61b615da46327c9050d624b0a3783ba21c6b125.googledrive.com/host/0B5Kp-cB1sXJrfnZ4NHZ0S1V3UTJZcDFra3RwUFZjQXY5WVZzUkwtTTd0Z1IyR1JmbDZPSVk/resolvconf-reinit/ > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From takao.shinji at lab.ntt.co.jp Tue May 19 06:41:10 2015 From: takao.shinji at lab.ntt.co.jp (Takao, Shinji) Date: Tue, 19 May 2015 15:41:10 +0900 Subject: jaxws tmp files may cause disk full Message-ID: <555ADB06.8040209@lab.ntt.co.jp> Hi all, One of my customer encountered a disk full error and found that the /tmp was filled with files "jaxws<19 numbers>.bin". I could not find a known issue like it, but noticed that the jaxws code in openjdk may leave temporary files in the /tmp. I suggest a fix for the code as attached. Please note that I have not confirmed that the fix works, but I would like to show you it now because it may take some time to confirm, and necessity for the fix looks rather obvious for me. Thanks, Shinji -------------- next part -------------- diff -r 45ef73bb85c1 -r 455600e57dd2 src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerConnectionImpl.java --- a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerConnectionImpl.java Thu May 14 12:38:10 2015 -0700 +++ b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerConnectionImpl.java Tue May 19 10:09:15 2015 +0900 @@ -168,6 +168,7 @@ public void close() throws IOException { if (!closed) { readAll(); + in.close(); super.close(); closed = true; } @@ -195,6 +196,7 @@ // This causes problems for streaming in one-way cases in.readAll(); try { + in.close(); super.close(); } catch(IOException ioe) { // Ignoring purposefully. From sean.coffey at oracle.com Tue May 19 10:04:23 2015 From: sean.coffey at oracle.com (=?Shift_JIS?B?U2VhJ24gQ29mZmV5?=) Date: Tue, 19 May 2015 11:04:23 +0100 Subject: jaxws tmp files may cause disk full In-Reply-To: <555ADB06.8040209@lab.ntt.co.jp> References: <555ADB06.8040209@lab.ntt.co.jp> Message-ID: <555B0AA7.4000509@oracle.com> The super.close() call should take care of closing the stream. No need of the extra close call. Your problem seems to stem from this code : http://hg.openjdk.java.net/jdk9/jdk9/jaxws/file/tip/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/ReadAllStream.java#l115 The temp files need to be deleted. Regards, Sean. On 19/05/2015 07:41, Takao, Shinji wrote: > Hi all, > > One of my customer encountered a disk full error and found > that the /tmp was filled with files "jaxws<19 numbers>.bin". > > I could not find a known issue like it, but noticed that > the jaxws code in openjdk may leave temporary files in the /tmp. > > I suggest a fix for the code as attached. > > Please note that I have not confirmed that the fix works, > but I would like to show you it now because it may take > some time to confirm, and necessity for the fix looks > rather obvious for me. > > Thanks, > Shinji > From sean.coffey at oracle.com Tue May 19 11:14:36 2015 From: sean.coffey at oracle.com (=?Shift_JIS?B?U2VhJ24gQ29mZmV5?=) Date: Tue, 19 May 2015 12:14:36 +0100 Subject: jaxws tmp files may cause disk full In-Reply-To: <555B0AA7.4000509@oracle.com> References: <555ADB06.8040209@lab.ntt.co.jp> <555B0AA7.4000509@oracle.com> Message-ID: <555B1B1C.1010600@oracle.com> I should have noticed that ServerConnectionImpl is using the ReadAllStream class. In that case, the custom close method where the delete happens would need to be called. Patch should work but best for jaxws engineers to comment. I've logged a bug report for you at https://bugs.openjdk.java.net/browse/JDK-8080662 Regards, Sean. On 19/05/2015 11:04, Sea'n Coffey wrote: > The super.close() call should take care of closing the stream. No need > of the extra close call. > > Your problem seems to stem from this code : > http://hg.openjdk.java.net/jdk9/jdk9/jaxws/file/tip/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/ReadAllStream.java#l115 > > The temp files need to be deleted. > > Regards, > Sean. > > On 19/05/2015 07:41, Takao, Shinji wrote: >> Hi all, >> >> One of my customer encountered a disk full error and found >> that the /tmp was filled with files "jaxws<19 numbers>.bin". >> >> I could not find a known issue like it, but noticed that >> the jaxws code in openjdk may leave temporary files in the /tmp. >> >> I suggest a fix for the code as attached. >> >> Please note that I have not confirmed that the fix works, >> but I would like to show you it now because it may take >> some time to confirm, and necessity for the fix looks >> rather obvious for me. >> >> Thanks, >> Shinji >> From rob.mckenna at oracle.com Wed May 20 12:24:41 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 20 May 2015 13:24:41 +0100 Subject: RFR: 8077155: LoginContext Subject ignored by jdk8 sun.net.www.protocol.http.HttpURLConnection Message-ID: <555C7D09.8010907@oracle.com> Hi folks, Looking for a review of this webrev: http://cr.openjdk.java.net/~robm/8077155/webrev.01/ Basically the subjects credentials are not available to HttpURLConnection.getInputStream0 since it now runs in a doPrivileged block. Changing that to doPrivilegedWithCombiner allows getInputStream0 access to the AccessControlContext's DomainCombiner and the subjects associated credentials. -Rob From michael.x.mcmahon at oracle.com Wed May 20 12:34:50 2015 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 20 May 2015 13:34:50 +0100 Subject: RFR: 8077155: LoginContext Subject ignored by jdk8 sun.net.www.protocol.http.HttpURLConnection In-Reply-To: <555C7D09.8010907@oracle.com> References: <555C7D09.8010907@oracle.com> Message-ID: <555C7F6A.3040002@oracle.com> Rob, There are a few more places where the same limited doPrivileged call occurs in HttpURLConnection and which need the same change. Michael On 20/05/15 13:24, Rob McKenna wrote: > Hi folks, > > Looking for a review of this webrev: > > http://cr.openjdk.java.net/~robm/8077155/webrev.01/ > > Basically the subjects credentials are not available to > HttpURLConnection.getInputStream0 since it now runs in a doPrivileged > block. Changing that to doPrivilegedWithCombiner allows > getInputStream0 access to the AccessControlContext's DomainCombiner > and the subjects associated credentials. > > -Rob From rob.mckenna at oracle.com Wed May 20 12:59:37 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 20 May 2015 13:59:37 +0100 Subject: RFR: 8077155: LoginContext Subject ignored by jdk8 sun.net.www.protocol.http.HttpURLConnection In-Reply-To: <555C7F6A.3040002@oracle.com> References: <555C7D09.8010907@oracle.com> <555C7F6A.3040002@oracle.com> Message-ID: <555C8539.6030400@oracle.com> Gah, sorry, should have paid more attention to the original change: http://cr.openjdk.java.net/~robm/8077155/webrev.02/ -Rob On 20/05/15 13:34, Michael McMahon wrote: > Rob, > > There are a few more places where the same limited doPrivileged call occurs > in HttpURLConnection and which need the same change. > > Michael > > On 20/05/15 13:24, Rob McKenna wrote: >> Hi folks, >> >> Looking for a review of this webrev: >> >> http://cr.openjdk.java.net/~robm/8077155/webrev.01/ >> >> Basically the subjects credentials are not available to >> HttpURLConnection.getInputStream0 since it now runs in a doPrivileged >> block. Changing that to doPrivilegedWithCombiner allows >> getInputStream0 access to the AccessControlContext's DomainCombiner >> and the subjects associated credentials. >> >> -Rob > From michael.x.mcmahon at oracle.com Wed May 20 13:04:00 2015 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 20 May 2015 14:04:00 +0100 Subject: RFR: 8077155: LoginContext Subject ignored by jdk8 sun.net.www.protocol.http.HttpURLConnection In-Reply-To: <555C8539.6030400@oracle.com> References: <555C7D09.8010907@oracle.com> <555C7F6A.3040002@oracle.com> <555C8539.6030400@oracle.com> Message-ID: <555C8640.6070803@oracle.com> Looks good. Michael. On 20/05/15 13:59, Rob McKenna wrote: > Gah, sorry, should have paid more attention to the original change: > > http://cr.openjdk.java.net/~robm/8077155/webrev.02/ > > -Rob > > On 20/05/15 13:34, Michael McMahon wrote: >> Rob, >> >> There are a few more places where the same limited doPrivileged call >> occurs >> in HttpURLConnection and which need the same change. >> >> Michael >> >> On 20/05/15 13:24, Rob McKenna wrote: >>> Hi folks, >>> >>> Looking for a review of this webrev: >>> >>> http://cr.openjdk.java.net/~robm/8077155/webrev.01/ >>> >>> Basically the subjects credentials are not available to >>> HttpURLConnection.getInputStream0 since it now runs in a doPrivileged >>> block. Changing that to doPrivilegedWithCombiner allows >>> getInputStream0 access to the AccessControlContext's DomainCombiner >>> and the subjects associated credentials. >>> >>> -Rob >> From weijun.wang at oracle.com Wed May 20 14:37:48 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 20 May 2015 22:37:48 +0800 Subject: RFR: 8077155: LoginContext Subject ignored by jdk8 sun.net.www.protocol.http.HttpURLConnection In-Reply-To: <555C7D09.8010907@oracle.com> References: <555C7D09.8010907@oracle.com> Message-ID: <555C9C3C.9090208@oracle.com> Hi Rob The src change is good. As for the test, this line will return the Subject you want Context.fromUserPass(WEB_USER, WEB_PASS, false).s() Thanks Max On 5/20/2015 8:24 PM, Rob McKenna wrote: > Hi folks, > > Looking for a review of this webrev: > > http://cr.openjdk.java.net/~robm/8077155/webrev.01/ > > Basically the subjects credentials are not available to > HttpURLConnection.getInputStream0 since it now runs in a doPrivileged > block. Changing that to doPrivilegedWithCombiner allows getInputStream0 > access to the AccessControlContext's DomainCombiner and the subjects > associated credentials. > > -Rob From brian.toal at gmail.com Fri May 22 06:56:02 2015 From: brian.toal at gmail.com (Brian Toal) Date: Thu, 21 May 2015 23:56:02 -0700 Subject: [PATCH] fix Inet4AddressImpl.lookupAllHostAddr returning unroutable addresses Message-ID: The fix for https://bugs.openjdk.java.net/browse/JDK-7180557 causes a regression for Mac OSX hosts connected to a VPN (or otherwise with more than network interface associated with the hostname). For example, when on Cisco VPN, the ifconfig is as follows: lo0: flags=8049 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 gif0: flags=8010 mtu 1280 stf0: flags=0<> mtu 1280 en0: flags=8863 mtu 1500 ether 28:cf:e9:1a:eb:6b inet6 fe80::2acf:e9ff:fe1a:eb6b%en0 prefixlen 64 scopeid 0x4 inet 192.168.0.106 netmask 0xffffff00 broadcast 192.168.0.255 media: autoselect status: active p2p0: flags=8843 mtu 2304 ether 0a:cf:e9:1a:eb:6b media: autoselect status: inactive utun0: flags=80d1 mtu 1320 inet 10.3.23.199 --> 10.3.23.199 netmask 0xffffc000 inet6 fe80::2acf:e9ff:fe1a:eb6b%utun0 prefixlen 64 scopeid 0x6 inet6 fe80::49cd:21e1:4c11:721d%utun0 prefixlen 128 scopeid 0x6 The hostname entry in DNS is associated with the utun0 interface, and 10.3.23.199 and all routes go through that interface. The 192.168.0.106 IP is my local wifi address, and is not used (other than to tunnel the VPN traffic when VPN is connected). Any connections to the 192.168 address, even from localhost, will fail (hang indefinitely, as all packets are dropped). The OS getaddrinfo calls, when passed the FQDN hostname only return the 10.3 address (getaddrinfo.c attached). Prior to the fix for JDK-7180557, getaddrinfo was being used and everything worked fine. As part of the fix, the following block was added for OSX only in the IPv4 path: + #ifdef MACOSX + /* If we're looking up the local machine, bypass DNS lookups and get + * address from getifaddrs. + */ + ret = lookupIfLocalhost(env, hostname, JNI_FALSE); + if (ret != NULL) { + JNU_ReleaseStringPlatformChars(env, host, hostname); + return ret; + } + #endif This code, which occurs before the usual path and applies only to localhost lookups, tries to "guess" the localaddress by interface enumeration. In the case of a VPN configuration, both en0 (192.168) and utun0 will match as they are active. So, for example, InetAddress.getAllByName("localhost FQDN"), will return both addresses. However, the getByName() call and most other code which implicitly uses the localhost will return only the first entry, which is the unroutable en0 address. The host is configured correctly and other processes all resolve the hostname correctly. The issue is specific to this OSX workaround. On the IPv6 path for the same fix, the lookupIfLocalhost workaround was only applied *if* the original lookup via the usual routines failed. The attached patch follows the same approach in the IPv4 path, if the orginal lookup fails then call lookupIfLocalhost If this was applied to the IPv4 path. The patch fixes the issue without regressing the hosts that triggered this fix. # HG changeset patch # User btoal # Date 1432276472 25200 # Thu May 21 23:34:32 2015 -0700 # Node ID 24cf7a8a8bf4f489da6b2506bcb57cb329a93593 # Parent 20e6cadfac43717a81d99daff5e769de695992cd Only call lookupIfLocalhost if getaddrinfo call errors to avoid resolving to a incorrect address. diff -r 20e6cadfac43 -r 24cf7a8a8bf4 src/solaris/native/java/net/Inet4AddressImpl.c --- a/src/solaris/native/java/net/Inet4AddressImpl.c Thu Feb 05 13:00:26 2015 +0100 +++ b/src/solaris/native/java/net/Inet4AddressImpl.c Thu May 21 23:34:32 2015 -0700 @@ -172,20 +172,19 @@ return NULL; } -#ifdef MACOSX - /* If we're looking up the local machine, bypass DNS lookups and get - * address from getifaddrs. - */ - ret = lookupIfLocalhost(env, hostname, JNI_FALSE); - if (ret != NULL || (*env)->ExceptionCheck(env)) { - JNU_ReleaseStringPlatformChars(env, host, hostname); - return ret; - } -#endif - error = getaddrinfo(hostname, NULL, &hints, &res); if (error) { +#ifdef MACOSX + /* If we're looking up the local machine, bypass DNS lookups and get + * address from getifaddrs. + */ + ret = lookupIfLocalhost(env, hostname, JNI_FALSE); + if (ret != NULL || (*env)->ExceptionCheck(env)) { + JNU_ReleaseStringPlatformChars(env, host, hostname); + return ret; + } +#endif /* report error */ ThrowUnknownHostExceptionWithGaiError(env, hostname, error); JNU_ReleaseStringPlatformChars(env, host, hostname); -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.mckenna at oracle.com Fri May 22 15:05:55 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 22 May 2015 16:05:55 +0100 Subject: [PATCH] fix Inet4AddressImpl.lookupAllHostAddr returning unroutable addresses In-Reply-To: References: Message-ID: <555F45D3.4020308@oracle.com> Hi Brian, By coincidence I just started looking at this today myself. We have an existing bug filed for this issue: https://bugs.openjdk.java.net/browse/JDK-8080819 The diagnosis looks good. -Rob On 22/05/15 07:56, Brian Toal wrote: > The fix for https://bugs.openjdk.java.net/browse/JDK-7180557 causes a > regression for Mac OSX hosts connected to a VPN (or otherwise with more > than network > interface associated with the hostname). > > For example, when on Cisco VPN, the ifconfig is as follows: > > lo0: flags=8049 mtu 16384 > options=3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > gif0: flags=8010 mtu 1280 > stf0: flags=0<> mtu 1280 > en0: flags=8863 mtu 1500 > ether 28:cf:e9:1a:eb:6b > inet6 fe80::2acf:e9ff:fe1a:eb6b%en0 prefixlen 64 scopeid 0x4 > inet 192.168.0.106 netmask 0xffffff00 broadcast 192.168.0.255 > media: autoselect > status: active > p2p0: flags=8843 mtu 2304 > ether 0a:cf:e9:1a:eb:6b > media: autoselect > status: inactive > utun0: flags=80d1 mtu 1320 > inet 10.3.23.199 --> 10.3.23.199 netmask 0xffffc000 > inet6 fe80::2acf:e9ff:fe1a:eb6b%utun0 prefixlen 64 scopeid 0x6 > inet6 fe80::49cd:21e1:4c11:721d%utun0 prefixlen 128 scopeid 0x6 > > The hostname entry in DNS is associated with the utun0 interface, and > 10.3.23.199 and all routes go through that interface. The 192.168.0.106 > IP is my local wifi address, and is not used (other than to tunnel the > VPN traffic when VPN is connected). Any connections to the 192.168 > address, even from localhost, will fail (hang indefinitely, as all > packets are dropped). > > The OS getaddrinfo calls, when passed the FQDN hostname only return the > 10.3 address (getaddrinfo.c attached). > > Prior to the fix for JDK-7180557, getaddrinfo was being used and > everything worked fine. As part of the fix, the following block was > added for OSX only in the IPv4 path: > > + #ifdef MACOSX > + /* If we're looking up the local machine, bypass DNS lookups and get > + * address from getifaddrs. > + */ > + ret = lookupIfLocalhost(env, hostname, JNI_FALSE); > + if (ret != NULL) { > + JNU_ReleaseStringPlatformChars(env, host, hostname); > + return ret; > + } > + #endif > > This code, which occurs before the usual path and applies only to > localhost lookups, tries to "guess" the localaddress by interface > enumeration. In the case of a VPN configuration, both en0 (192.168) and > utun0 will match as they are active. So, for example, > InetAddress.getAllByName("localhost FQDN"), will return both addresses. > However, the getByName() call and most other code which implicitly uses > the localhost will return only the first entry, which is the unroutable > en0 address. > > The host is configured correctly and other processes all resolve the > hostname correctly. The issue is specific to this OSX workaround. > > On the IPv6 path for the same fix, the lookupIfLocalhost workaround was > only applied *if* the original lookup via the usual routines failed. The > attached patch follows the same approach in the IPv4 path, if the > orginal lookup fails then call lookupIfLocalhost If this was applied to > the IPv4 path. The patch fixes the issue without regressing the hosts > that triggered this fix. > > # HG changeset patch > # User btoal > # Date 1432276472 25200 > # Thu May 21 23:34:32 2015 -0700 > # Node ID 24cf7a8a8bf4f489da6b2506bcb57cb329a93593 > # Parent 20e6cadfac43717a81d99daff5e769de695992cd > Only call lookupIfLocalhost if getaddrinfo call errors to avoid > resolving to a incorrect address. > > diff -r 20e6cadfac43 -r 24cf7a8a8bf4 > src/solaris/native/java/net/Inet4AddressImpl.c > --- a/src/solaris/native/java/net/Inet4AddressImpl.c Thu Feb 05 > 13:00:26 2015 +0100 > +++ b/src/solaris/native/java/net/Inet4AddressImpl.c Thu May 21 > 23:34:32 2015 -0700 > @@ -172,20 +172,19 @@ > return NULL; > } > > -#ifdef MACOSX > - /* If we're looking up the local machine, bypass DNS lookups and get > - * address from getifaddrs. > - */ > - ret = lookupIfLocalhost(env, hostname, JNI_FALSE); > - if (ret != NULL || (*env)->ExceptionCheck(env)) { > - JNU_ReleaseStringPlatformChars(env, host, hostname); > - return ret; > - } > -#endif > - > error = getaddrinfo(hostname, NULL, &hints, &res); > > if (error) { > +#ifdef MACOSX > + /* If we're looking up the local machine, bypass DNS lookups > and get > + * address from getifaddrs. > + */ > + ret = lookupIfLocalhost(env, hostname, JNI_FALSE); > + if (ret != NULL || (*env)->ExceptionCheck(env)) { > + JNU_ReleaseStringPlatformChars(env, host, hostname); > + return ret; > + } > +#endif > /* report error */ > ThrowUnknownHostExceptionWithGaiError(env, hostname, error); > JNU_ReleaseStringPlatformChars(env, host, hostname); From rob.mckenna at oracle.com Fri May 22 15:14:43 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 22 May 2015 16:14:43 +0100 Subject: 8080819: [PATCH] fix Inet4AddressImpl.lookupAllHostAddr returning unroutable addresses In-Reply-To: <555F45D3.4020308@oracle.com> References: <555F45D3.4020308@oracle.com> Message-ID: <555F47E3.4020108@oracle.com> Adding bug id to subject for reference. -Rob On 22/05/15 16:05, Rob McKenna wrote: > Hi Brian, > > By coincidence I just started looking at this today myself. > > We have an existing bug filed for this issue: > https://bugs.openjdk.java.net/browse/JDK-8080819 > > The diagnosis looks good. > > -Rob > > On 22/05/15 07:56, Brian Toal wrote: >> The fix for https://bugs.openjdk.java.net/browse/JDK-7180557 causes a >> regression for Mac OSX hosts connected to a VPN (or otherwise with more >> than network >> interface associated with the hostname). >> >> For example, when on Cisco VPN, the ifconfig is as follows: >> >> lo0: flags=8049 mtu 16384 >> options=3 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 >> inet 127.0.0.1 netmask 0xff000000 >> inet6 ::1 prefixlen 128 >> gif0: flags=8010 mtu 1280 >> stf0: flags=0<> mtu 1280 >> en0: flags=8863 mtu 1500 >> ether 28:cf:e9:1a:eb:6b >> inet6 fe80::2acf:e9ff:fe1a:eb6b%en0 prefixlen 64 scopeid 0x4 >> inet 192.168.0.106 netmask 0xffffff00 broadcast 192.168.0.255 >> media: autoselect >> status: active >> p2p0: flags=8843 mtu 2304 >> ether 0a:cf:e9:1a:eb:6b >> media: autoselect >> status: inactive >> utun0: flags=80d1 mtu 1320 >> inet 10.3.23.199 --> 10.3.23.199 netmask 0xffffc000 >> inet6 fe80::2acf:e9ff:fe1a:eb6b%utun0 prefixlen 64 scopeid 0x6 >> inet6 fe80::49cd:21e1:4c11:721d%utun0 prefixlen 128 scopeid 0x6 >> >> The hostname entry in DNS is associated with the utun0 interface, and >> 10.3.23.199 and all routes go through that interface. The 192.168.0.106 >> IP is my local wifi address, and is not used (other than to tunnel the >> VPN traffic when VPN is connected). Any connections to the 192.168 >> address, even from localhost, will fail (hang indefinitely, as all >> packets are dropped). >> >> The OS getaddrinfo calls, when passed the FQDN hostname only return the >> 10.3 address (getaddrinfo.c attached). >> >> Prior to the fix for JDK-7180557, getaddrinfo was being used and >> everything worked fine. As part of the fix, the following block was >> added for OSX only in the IPv4 path: >> >> + #ifdef MACOSX >> + /* If we're looking up the local machine, bypass DNS lookups and >> get >> + * address from getifaddrs. >> + */ >> + ret = lookupIfLocalhost(env, hostname, JNI_FALSE); >> + if (ret != NULL) { >> + JNU_ReleaseStringPlatformChars(env, host, hostname); >> + return ret; >> + } >> + #endif >> >> This code, which occurs before the usual path and applies only to >> localhost lookups, tries to "guess" the localaddress by interface >> enumeration. In the case of a VPN configuration, both en0 (192.168) and >> utun0 will match as they are active. So, for example, >> InetAddress.getAllByName("localhost FQDN"), will return both addresses. >> However, the getByName() call and most other code which implicitly uses >> the localhost will return only the first entry, which is the unroutable >> en0 address. >> >> The host is configured correctly and other processes all resolve the >> hostname correctly. The issue is specific to this OSX workaround. >> >> On the IPv6 path for the same fix, the lookupIfLocalhost workaround was >> only applied *if* the original lookup via the usual routines failed. The >> attached patch follows the same approach in the IPv4 path, if the >> orginal lookup fails then call lookupIfLocalhost If this was applied to >> the IPv4 path. The patch fixes the issue without regressing the hosts >> that triggered this fix. >> >> # HG changeset patch >> # User btoal >> # Date 1432276472 25200 >> # Thu May 21 23:34:32 2015 -0700 >> # Node ID 24cf7a8a8bf4f489da6b2506bcb57cb329a93593 >> # Parent 20e6cadfac43717a81d99daff5e769de695992cd >> Only call lookupIfLocalhost if getaddrinfo call errors to avoid >> resolving to a incorrect address. >> >> diff -r 20e6cadfac43 -r 24cf7a8a8bf4 >> src/solaris/native/java/net/Inet4AddressImpl.c >> --- a/src/solaris/native/java/net/Inet4AddressImpl.c Thu Feb 05 >> 13:00:26 2015 +0100 >> +++ b/src/solaris/native/java/net/Inet4AddressImpl.c Thu May 21 >> 23:34:32 2015 -0700 >> @@ -172,20 +172,19 @@ >> return NULL; >> } >> >> -#ifdef MACOSX >> - /* If we're looking up the local machine, bypass DNS lookups and get >> - * address from getifaddrs. >> - */ >> - ret = lookupIfLocalhost(env, hostname, JNI_FALSE); >> - if (ret != NULL || (*env)->ExceptionCheck(env)) { >> - JNU_ReleaseStringPlatformChars(env, host, hostname); >> - return ret; >> - } >> -#endif >> - >> error = getaddrinfo(hostname, NULL, &hints, &res); >> >> if (error) { >> +#ifdef MACOSX >> + /* If we're looking up the local machine, bypass DNS lookups >> and get >> + * address from getifaddrs. >> + */ >> + ret = lookupIfLocalhost(env, hostname, JNI_FALSE); >> + if (ret != NULL || (*env)->ExceptionCheck(env)) { >> + JNU_ReleaseStringPlatformChars(env, host, hostname); >> + return ret; >> + } >> +#endif >> /* report error */ >> ThrowUnknownHostExceptionWithGaiError(env, hostname, error); >> JNU_ReleaseStringPlatformChars(env, host, hostname); From brian.toal at gmail.com Fri May 22 15:33:37 2015 From: brian.toal at gmail.com (Brian Toal) Date: Fri, 22 May 2015 08:33:37 -0700 Subject: [PATCH] fix Inet4AddressImpl.lookupAllHostAddr returning unroutable addresses In-Reply-To: <555F45D3.4020308@oracle.com> References: <555F45D3.4020308@oracle.com> Message-ID: Yah we raised a SR with Oracle support regarding the problem and in the mean time fixed it on OpenJDK. Maybe you were the engineer assigned the SR or the resulting bug? Hopefully the submission of this patch dedupes work someone would have to do to address the issue. On Fri, May 22, 2015 at 8:05 AM, Rob McKenna wrote: > Hi Brian, > > By coincidence I just started looking at this today myself. > > We have an existing bug filed for this issue: > https://bugs.openjdk.java.net/browse/JDK-8080819 > > The diagnosis looks good. > > -Rob > > > On 22/05/15 07:56, Brian Toal wrote: > >> The fix for https://bugs.openjdk.java.net/browse/JDK-7180557 causes a >> regression for Mac OSX hosts connected to a VPN (or otherwise with more >> than network >> interface associated with the hostname). >> >> For example, when on Cisco VPN, the ifconfig is as follows: >> >> lo0: flags=8049 mtu 16384 >> options=3 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 >> inet 127.0.0.1 netmask 0xff000000 >> inet6 ::1 prefixlen 128 >> gif0: flags=8010 mtu 1280 >> stf0: flags=0<> mtu 1280 >> en0: flags=8863 mtu 1500 >> ether 28:cf:e9:1a:eb:6b >> inet6 fe80::2acf:e9ff:fe1a:eb6b%en0 prefixlen 64 scopeid 0x4 >> inet 192.168.0.106 netmask 0xffffff00 broadcast 192.168.0.255 >> media: autoselect >> status: active >> p2p0: flags=8843 mtu 2304 >> ether 0a:cf:e9:1a:eb:6b >> media: autoselect >> status: inactive >> utun0: flags=80d1 mtu 1320 >> inet 10.3.23.199 --> 10.3.23.199 netmask 0xffffc000 >> inet6 fe80::2acf:e9ff:fe1a:eb6b%utun0 prefixlen 64 scopeid 0x6 >> inet6 fe80::49cd:21e1:4c11:721d%utun0 prefixlen 128 scopeid 0x6 >> >> The hostname entry in DNS is associated with the utun0 interface, and >> 10.3.23.199 and all routes go through that interface. The 192.168.0.106 >> IP is my local wifi address, and is not used (other than to tunnel the >> VPN traffic when VPN is connected). Any connections to the 192.168 >> address, even from localhost, will fail (hang indefinitely, as all >> packets are dropped). >> >> The OS getaddrinfo calls, when passed the FQDN hostname only return the >> 10.3 address (getaddrinfo.c attached). >> >> Prior to the fix for JDK-7180557, getaddrinfo was being used and >> everything worked fine. As part of the fix, the following block was >> added for OSX only in the IPv4 path: >> >> + #ifdef MACOSX >> + /* If we're looking up the local machine, bypass DNS lookups and get >> + * address from getifaddrs. >> + */ >> + ret = lookupIfLocalhost(env, hostname, JNI_FALSE); >> + if (ret != NULL) { >> + JNU_ReleaseStringPlatformChars(env, host, hostname); >> + return ret; >> + } >> + #endif >> >> This code, which occurs before the usual path and applies only to >> localhost lookups, tries to "guess" the localaddress by interface >> enumeration. In the case of a VPN configuration, both en0 (192.168) and >> utun0 will match as they are active. So, for example, >> InetAddress.getAllByName("localhost FQDN"), will return both addresses. >> However, the getByName() call and most other code which implicitly uses >> the localhost will return only the first entry, which is the unroutable >> en0 address. >> >> The host is configured correctly and other processes all resolve the >> hostname correctly. The issue is specific to this OSX workaround. >> >> On the IPv6 path for the same fix, the lookupIfLocalhost workaround was >> only applied *if* the original lookup via the usual routines failed. The >> attached patch follows the same approach in the IPv4 path, if the >> orginal lookup fails then call lookupIfLocalhost If this was applied to >> the IPv4 path. The patch fixes the issue without regressing the hosts >> that triggered this fix. >> >> # HG changeset patch >> # User btoal >> # Date 1432276472 25200 >> # Thu May 21 23:34:32 2015 -0700 >> # Node ID 24cf7a8a8bf4f489da6b2506bcb57cb329a93593 >> # Parent 20e6cadfac43717a81d99daff5e769de695992cd >> Only call lookupIfLocalhost if getaddrinfo call errors to avoid >> resolving to a incorrect address. >> >> diff -r 20e6cadfac43 -r 24cf7a8a8bf4 >> src/solaris/native/java/net/Inet4AddressImpl.c >> --- a/src/solaris/native/java/net/Inet4AddressImpl.c Thu Feb 05 >> 13:00:26 2015 +0100 >> +++ b/src/solaris/native/java/net/Inet4AddressImpl.c Thu May 21 >> 23:34:32 2015 -0700 >> @@ -172,20 +172,19 @@ >> return NULL; >> } >> >> -#ifdef MACOSX >> - /* If we're looking up the local machine, bypass DNS lookups and get >> - * address from getifaddrs. >> - */ >> - ret = lookupIfLocalhost(env, hostname, JNI_FALSE); >> - if (ret != NULL || (*env)->ExceptionCheck(env)) { >> - JNU_ReleaseStringPlatformChars(env, host, hostname); >> - return ret; >> - } >> -#endif >> - >> error = getaddrinfo(hostname, NULL, &hints, &res); >> >> if (error) { >> +#ifdef MACOSX >> + /* If we're looking up the local machine, bypass DNS lookups >> and get >> + * address from getifaddrs. >> + */ >> + ret = lookupIfLocalhost(env, hostname, JNI_FALSE); >> + if (ret != NULL || (*env)->ExceptionCheck(env)) { >> + JNU_ReleaseStringPlatformChars(env, host, hostname); >> + return ret; >> + } >> +#endif >> /* report error */ >> ThrowUnknownHostExceptionWithGaiError(env, hostname, error); >> JNU_ReleaseStringPlatformChars(env, host, hostname); >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Mon May 25 14:01:40 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 25 May 2015 15:01:40 +0100 Subject: RFR : 8072384 : Setting IP_TOS on java.net sockets not working on unix In-Reply-To: <5512EEA3.8020400@oracle.com> References: <54F05700.90402@oracle.com> <5512EEA3.8020400@oracle.com> Message-ID: <55632B44.4030508@oracle.com> Jumping back on this issue...Michael identified a regression on linux with my last webrev. It was connected with IPv6 sockets connecting to IPv4 interfaces. Linux seems to cater for IP_TOS settings in this area. I've modified my last webrev so that we only 'promote' IP_TOS requests to IPV6_TCLASS requests if dealing with solaris or macosx. I discovered one bug where setting IP_TOS on the server (remote) socket in an IPv6 <-> IPv6 environment wasn't working (on the server SYN reply packet) So overcome that, setting both the TOS and TCLASS values works and setsockopt on linux doesn't complain with such an approach. A simple server side test using the new Sockets API might be : jdk.net.Sockets.setOption(ss, java.net.StandardSocketOptions.IP_TOS, 128); ss.bind(new InetSocketAddress("2606:b400:818:8f:xxxx:xxxx:xxxx:xxxx", 19001)); ss.accept(); This is the server socket setsockopt strace with new fix : 16788 setsockopt(4, SOL_IPV6, IPV6_V6ONLY, [0], 4) = 0 16788 setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 16788 setsockopt(4, SOL_IPV6, 0x21 /* IPV6_??? */, [1], 4) = 0 16788 setsockopt(4, SOL_IPV6, 0x43 /* IPV6_??? */, [128], 4) = 0 16788 setsockopt(4, SOL_IP, IP_TOS, [128], 4) = 0 Note : 0x43 == IPV6_TCLASS 67 0x21 == IPV6_FLOWINFO_SEND 33 latest webrev : http://cr.openjdk.java.net/~coffeys/webrev.tos-may22/webrev/ Regards, Sean. On 25/03/15 17:21, Se?n Coffey wrote: > I didn't see any review on this request yet. I've modified the > OptionsTest to test for IP_TOS on ServerSockets. The > -Djava.net.preferIPv4Stack=true addition also allows the code to test > both stacks where applicable. > > http://cr.openjdk.java.net/~coffeys/webrev.8072384.jdk9.v2/webrev/ > > regards, > Sean. > > On 27/02/15 11:37, Se?n Coffey wrote: >> It looks like setting and getting the IP_TOS values on the java.net >> Sockets is currently broken for some scenarios. It's not possible to >> set the value on a ServerSocket via the jdk.net.Sockets.setOption >> API. See below for a webrev I'm proposing. It basically makes best >> efforts to set the IP_TOS value by mapping it to the IPV6_TCLASS >> option in an IPV6 enabled environment. NIO follows a similar approach. >> >> Some of the comments in NET_SetSockOpt seem to be legacy and I've >> removed the no-op that was in place for IP_TOS. A corner case of >> setting of IP_TOS was found on Solaris. It doesn't seem to support >> setting the value once the socket is connected. I've handled this via >> catching of exception and we should be ok with this since the spec >> doesn't make any promises in this area if the socket is connected. >> >> I've been testing various fixes across IPv4/v6 sockets on Solaris, >> Linux and macosx. So far, the proposed changes seem to work and >> wireshark traces help to confirm that TOS/TCLASS values are being set. >> >> I still need to see if I can improve the getOpt logic for IP_TOS. At >> the moment, it can return a cached value which may not represent the >> true value in place at kernel socket level. I'll also improve test >> coverage in this area. >> >> bug report : https://bugs.openjdk.java.net/browse/JDK-8072384 >> webrev : >> http://cr.openjdk.java.net/~coffeys/webrev.8072384.jdk9.v1/webrev/ >> >> regards, >> Sean. >> >> > From mark.sheppard at oracle.com Tue May 26 19:21:46 2015 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 26 May 2015 20:21:46 +0100 Subject: RFR: JDK-8041677 - java/net/MulticastSocket/TestInterfaces failed on Oracle VM Virtual Ethernet Adapter Message-ID: <5564C7CA.3090703@oracle.com> 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 test. A conditional statement excludes Teredo from the latter part of the test, so the conditional is moved to the start of the while loop regards Mark From Alan.Bateman at oracle.com Tue May 26 19:34:19 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 May 2015 20:34:19 +0100 Subject: RFR: JDK-8041677 - java/net/MulticastSocket/TestInterfaces failed on Oracle VM Virtual Ethernet Adapter In-Reply-To: <5564C7CA.3090703@oracle.com> References: <5564C7CA.3090703@oracle.com> Message-ID: <5564CABB.7060905@oracle.com> 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 that the Teredo interfaces causes issue, due to its > dynamic configuration, when included in > the test. A conditional statement excludes Teredo from the latter part > of the test, so > the conditional is moved to the start of the while loop This looks okay to me. -Alan From mark.sheppard at oracle.com Tue May 26 19:34:26 2015 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 26 May 2015 20:34:26 +0100 Subject: RFR: JDK-8077377 - java/net/MulticastSocket/SetOutgoingIf.java fails intermittently with NullPointerException Message-ID: <5564CAC2.9090105@oracle.com> 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 NetworkInterface lookup based on the received address. Change adds a test that the "from" NetworkInterface is not null. regards Mark From Alan.Bateman at oracle.com Tue May 26 19:43:02 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 May 2015 20:43:02 +0100 Subject: RFR: JDK-8077377 - java/net/MulticastSocket/SetOutgoingIf.java fails intermittently with NullPointerException In-Reply-To: <5564CAC2.9090105@oracle.com> References: <5564CAC2.9090105@oracle.com> Message-ID: <5564CCC6.7000607@oracle.com> 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/JDK-8077377 > > it is possible that "stray" packets can be received in this > MulticastSocket test, and > this results in a NPE from the NetworkInterface lookup based on the > received address. > Change adds a test that the "from" NetworkInterface is not null. If I read this correctly then it just ignores the packet when it comes from a non-local interface (or interference from something else on the network). Should the commented out throwing on RuntimeException be removed while you are there? -Alan. From mark.sheppard at oracle.com Tue May 26 20:06:40 2015 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 26 May 2015 21:06:40 +0100 Subject: RFR: JDK-8041677 - java/net/MulticastSocket/TestInterfaces failed on Oracle VM Virtual Ethernet Adapter In-Reply-To: <5564CABB.7060905@oracle.com> References: <5564C7CA.3090703@oracle.com> <5564CABB.7060905@oracle.com> Message-ID: <5564D250.9000208@oracle.com> 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 that the Teredo interfaces causes issue, due to >> its dynamic configuration, when included in >> the test. A conditional statement excludes Teredo from the latter >> part of the test, so >> the conditional is moved to the start of the while loop > This looks okay to me. > > -Alan From mark.sheppard at oracle.com Tue May 26 20:15:42 2015 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 26 May 2015 21:15:42 +0100 Subject: RFR: JDK-8077377 - java/net/MulticastSocket/SetOutgoingIf.java fails intermittently with NullPointerException In-Reply-To: <5564CCC6.7000607@oracle.com> References: <5564CAC2.9090105@oracle.com> <5564CCC6.7000607@oracle.com> Message-ID: <5564D46E.4080303@oracle.com> Hi Alan, yes, that's about it. The test is just logging that expected interface is not equal to from. So ignoring the stray packet seems reasonable and overcomes the NPE. We could log the fact that a stray packet has been received if (from != null) { if (!from.equals(shouldbe)) { System.out.println("Packets on group " + group + " should come from " + shouldbe.getName() + ", but came from " + from.getName()); //throw new RuntimeException("Test failed."); } } else { System.out.println("Unexpected packet received from " + packet.getAddress()); } I 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/JDK-8077377 >> >> it is possible that "stray" packets can be received in this >> MulticastSocket test, and >> this results in a NPE from the NetworkInterface lookup based on the >> received address. >> Change adds a test that the "from" NetworkInterface is not null. > If I read this correctly then it just ignores the packet when it comes > from a non-local interface (or interference from something else on the > network). > > Should the commented out throwing on RuntimeException be removed while > you are there? > > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue May 26 21:12:24 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 26 May 2015 22:12:24 +0100 Subject: RFR: JDK-8041677 - java/net/MulticastSocket/TestInterfaces failed on Oracle VM Virtual Ethernet Adapter In-Reply-To: <5564C7CA.3090703@oracle.com> References: <5564C7CA.3090703@oracle.com> Message-ID: <9D4CBFB9-8523-4C52-9898-5B6A8B57AE2A@oracle.com> Looks fine. Not for now, but sometime we should consider adding a utility to the test library to retrieve an appropriate set of network interfaces suitable for use in tests ( rather than patching all these tests individually ). -Chris. > 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 its dynamic configuration, when included in > the test. A conditional statement excludes Teredo from the latter part of the test, so > the conditional is moved to the start of the while loop > > regards > Mark > From chris.hegarty at oracle.com Tue May 26 21:22:26 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 26 May 2015 22:22:26 +0100 Subject: RFR: JDK-8077377 - java/net/MulticastSocket/SetOutgoingIf.java fails intermittently with NullPointerException In-Reply-To: <5564CAC2.9090105@oracle.com> References: <5564CAC2.9090105@oracle.com> Message-ID: Looks fine Mark. We fixed a few other tests recently to be more tolerant of network interference. -Chris. > On 26 May 2015, at 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/JDK-8077377 > > it is possible that "stray" packets can be received in this MulticastSocket test, and > this results in a NPE from the NetworkInterface lookup based on the received address. > Change adds a test that the "from" NetworkInterface is not null. > > regards > Mark From mark.sheppard at oracle.com Wed May 27 11:58:06 2015 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 27 May 2015 12:58:06 +0100 Subject: RFR: JDK-8041677 - java/net/MulticastSocket/TestInterfaces failed on Oracle VM Virtual Ethernet Adapter In-Reply-To: <9D4CBFB9-8523-4C52-9898-5B6A8B57AE2A@oracle.com> References: <5564C7CA.3090703@oracle.com> <9D4CBFB9-8523-4C52-9898-5B6A8B57AE2A@oracle.com> Message-ID: <5565B14E.1030107@oracle.com> thanks Chris On 26/05/2015 22:12, Chris Hegarty wrote: > Looks fine. > > Not for now, but sometime we should consider adding a utility to the test library to retrieve an appropriate set of network interfaces suitable for use in tests ( rather than patching all these tests individually ). > > -Chris. > >> 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 its dynamic configuration, when included in >> the test. A conditional statement excludes Teredo from the latter part of the test, so >> the conditional is moved to the start of the while loop >> >> regards >> Mark >>