Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor
again thanks for the review and feedback, Alan patch amended as suggested http://cr.openjdk.java.net/~msheppar/8134577/webrev.08/ removed File.exists test in createNameService - lookup methods in HostsFileNameService already throw UHE for FileNotFoundException InetAddress.impl marked final removed references to JNDI added test for non-existent hosts file regards Mark On 06/01/2016 20:37, Alan Bateman wrote: On 06/01/2016 15:37, Mark Sheppard wrote: thanks for the feedback, Alan based on suggestions, all issues have been addressed and patch has been updated http://cr.openjdk.java.net/~msheppar/8134577/webrev.07 the following should be noted: ExtensionsWithLDAP.java is added to the exclude list with JDK-8134577 - This is on the problem list as it will need to be re-written The NameService associated with this test threw UnknownHostExceptions and added the host name to a List, which was then examined later in the test as a verification. The instantiation of a NameService is as intended, i.e. if jdk.net.hosts.file set and file exist then instantiate HostsFileNameService else instantiate PlatformNameService this is in keeping with previous initialization semantics - if the no service provider NameService created then the default NameService was instantiated. I think this looks quite good. If jdk.net.hosts.file is set to a file that doesn't exist then I think it should throw an exception or else just work as if the hosts file is empty. However, it's probably not worth spending time on as this mechanism is mostly for tests. There is still a reference to the JNDI-DNS provider in HostsFileNameService and I assume that should be removed as it's essentially a historical reference now. I assume InetAddress.impl can be changed to be final. For ExtensionsWithLDAP.java then you need to create an issue to track it and use that issue number when adding it to the exclude list. I think that is all I have on this topic. -Alan
RE: Patch for adding SO_REUSEPORT socket option
Hi Alan, In AbstractPlainSocketImpl, I am using the existing/default initializer so that there is only 1 initializer. However, it does not execute. That is the issue I am seeing. Any suggestion on the issue? Thanks, Lucy -Original Message- From: Alan Bateman [mailto:alan.bate...@oracle.com] Sent: Wednesday, January 06, 2016 7:38 AM To: Lu, Yingqi ; Volker Simonis Cc: net-dev@openjdk.java.net; Viswanathan, Sandhya ; Kharbas, Kishor ; Aundhe, Shirish ; Kaczmarek, Eric Subject: Re: Patch for adding SO_REUSEPORT socket option On 05/01/2016 18:56, Lu, Yingqi wrote: > Hi Alan, > > Sorry for the confusion. Let me be more detailed on the issue. > > In previous version of the patch, I added an initializer in SocketImpl.java > to load the libnet.so since the isReusePortAvailable and its native > implementation were there. Then, this time, I tried to move > isReusePortAvailable and its native implementation declaration down to > AbstractPlainSocketImpl therefore I removed the initializer block from > SocketImpl.java as well. Inside AbstractPlainSocketImpl.java, there is > already an initializer there by default to load the libnet.so. I was assuming > it would just load the library and the code would work. However, I found out > the initializer inside the AbstractPlainSocketimpl does not execute. After I > add back the initializer to SocketImpl, the code works. > > My question is: Is this a reasonable approach to do it by keeping both > initializers? > > Thanks very much for your help, > Lucy > When you updated AbstractPlainSocketImpl then is the new initializer before or after the current initializer? They run in declaration order so I'm wondering if this is the issue you are running into. -Alan
Re: Patch for adding SO_REUSEPORT socket option
On 07/01/2016 16:41, Lu, Yingqi wrote: Hi Alan, In AbstractPlainSocketImpl, I am using the existing/default initializer so that there is only 1 initializer. However, it does not execute. That is the issue I am seeing. Any suggestion on the issue? Are you 100% sure that your updated AbstractPlainSocketImpl is included in the build? I just did a quick check to add Thread.dumpStack() into that initializer and I see it running when creating a Socket or ServerSocket. I believe each of the platform implementations extend AbstractPlainSocketImpl so you should see it running on all platforms. -Alan
