From paul.sandoz at oracle.com Tue May 1 00:13:46 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 30 Apr 2018 17:13:46 -0700 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <12b66f2e-49d8-ec6b-d0fb-dc310152940b@oracle.com> References: <5AE2AC3C.4040902@oracle.com> <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> <6648FDC1-A3E0-4E6B-AA24-226550D56F66@oracle.com> <12b66f2e-49d8-ec6b-d0fb-dc310152940b@oracle.com> Message-ID: <85714E2C-CBEC-4483-9220-F21BFD5DF9B4@oracle.com> > On Apr 30, 2018, at 4:47 PM, Joe Wang wrote: >> >> ? >> >> It?s tempting (well to me at least) to generalize to a mismatch method (like for arrays) returning the mismatching location in bytes, then you can determine if one file is a prefix of another given the files sizes. Bound accepting methods would also be useful to mismatch on partial content (including within the same file). If you use memory mapped files we can use direct byte buffers to efficiently perform the mismatch. > > Are there real-life use cases? It may be useful for example to check if the files have the same header. > Yes, something like that. I was just searching for a more general abstraction e.g. mismatch, that can support equality and lexicographical comparison of file contents. Other use-cases tend pop out almost for free because of that :-) However, its possible to support the more advanced cases directly with mapped byte buffers. The good news is you can add isSameContent and if there is demand for mismatch add that, deriving the implementation of isSameContent from the new method. Paul. > We did a bit of use-case study where we compared a bunch of possible options, including read string with bound, or by specifying patterns, and/or read into a list with a regex/pattern as separator (vs the default line-separator). We concluded that readString is a popular demand, and it's usually a quick read of small files, e.g. a config file, a SQL query file and etc. The methods fulfill the process of String <==> File transformation, a straight and quick way of converting a String to File and vice versa. > > The demand for isSameContent isn't necessarily as popular as readString, but there were still some real use cases where people asked how to do it quickly. When we have String <==> File, it's natural to at least have a comparison method since String.equal is essential to it. Plus, we already had isSameFile. > > Best, > Joe > >> >> To Remi?s point this might dissuade/guide developers from using this method when there are other more efficient techniques available when operating at larger scales. However, it is unfortunately harder that it should be in Java to hash the contents of a file, a byte[] or ByteBuffer, according to some chosen algorithm (or a good default). >> >> Paul. > From john.r.rose at oracle.com Tue May 1 01:18:02 2018 From: john.r.rose at oracle.com (John Rose) Date: Mon, 30 Apr 2018 18:18:02 -0700 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <12b66f2e-49d8-ec6b-d0fb-dc310152940b@oracle.com> References: <5AE2AC3C.4040902@oracle.com> <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> <6648FDC1-A3E0-4E6B-AA24-226550D56F66@oracle.com> <12b66f2e-49d8-ec6b-d0fb-dc310152940b@oracle.com> Message-ID: On Apr 30, 2018, at 4:47 PM, Joe Wang wrote: > > Are there real-life use cases? It may be useful for example to check if the files have the same header. After equality comparison, lexical comparison is a key use case. By allowing the user to interpret the data around the mismatch, the comparison can be made sensitive to things like locales. As Paul implies, finding a mismatch is the correct operation to build equality checks on top of, because (a) a mismatch has to be detected anyway to prove inequality, and (b) giving the location of the mismatch, instead of throwing it away, unlocks a variety of other operations. If you want real-life use cases, look at uses of /usr/bin/cmp in Unix shell scripts. The cmp command is to Unix files what Paul's array mismatch methods are to Java arrays. Here's a man page reference: https://docs.oracle.com/cd/E19683-01/816-0210/6m6nb7m6c/index.html As with the array mismatch methods, the cmp command allows the user to specify optional offsets within each file to start comparing, as well as an optional length to stop comparing after. See the file BufferMismatch.java for the (partial) application of these ideas to NIO buffers. I suppose the Java-flavored version of "cmp - file" would be a file comparator which would take a byte buffer as a second operand, and return an indication of the location of the mismatch. Note that "cmp - file" compares a computed stream against a stored file. I think Paul and I have sketched a natural "sweet spot" for performing bitwise comparisons on stored data. It's up to you how much to implement. I suggest that, if you don't feel inspired to do it all in one go, that you leave room in the code for future expansions (maybe as with BufferMismatch), and perhaps file a follow-up RFE. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From huizhe.wang at oracle.com Tue May 1 01:20:07 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 30 Apr 2018 18:20:07 -0700 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <85714E2C-CBEC-4483-9220-F21BFD5DF9B4@oracle.com> References: <5AE2AC3C.4040902@oracle.com> <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> <6648FDC1-A3E0-4E6B-AA24-226550D56F66@oracle.com> <12b66f2e-49d8-ec6b-d0fb-dc310152940b@oracle.com> <85714E2C-CBEC-4483-9220-F21BFD5DF9B4@oracle.com> Message-ID: <99cf9e6d-8c19-165e-1e59-abe0a29e1c39@oracle.com> I see. Generalization vs solution in a specific scope, it's kind of a balancing art indeed :-) -Joe On 4/30/2018 5:13 PM, Paul Sandoz wrote: > >> On Apr 30, 2018, at 4:47 PM, Joe Wang wrote: >>> ? >>> >>> It?s tempting (well to me at least) to generalize to a mismatch method (like for arrays) returning the mismatching location in bytes, then you can determine if one file is a prefix of another given the files sizes. Bound accepting methods would also be useful to mismatch on partial content (including within the same file). If you use memory mapped files we can use direct byte buffers to efficiently perform the mismatch. >> Are there real-life use cases? It may be useful for example to check if the files have the same header. >> > Yes, something like that. I was just searching for a more general abstraction e.g. mismatch, that can support equality and lexicographical comparison of file contents. Other use-cases tend pop out almost for free because of that :-) However, its possible to support the more advanced cases directly with mapped byte buffers. > > The good news is you can add isSameContent and if there is demand for mismatch add that, deriving the implementation of isSameContent from the new method. > > Paul. > >> We did a bit of use-case study where we compared a bunch of possible options, including read string with bound, or by specifying patterns, and/or read into a list with a regex/pattern as separator (vs the default line-separator). We concluded that readString is a popular demand, and it's usually a quick read of small files, e.g. a config file, a SQL query file and etc. The methods fulfill the process of String <==> File transformation, a straight and quick way of converting a String to File and vice versa. >> >> The demand for isSameContent isn't necessarily as popular as readString, but there were still some real use cases where people asked how to do it quickly. When we have String <==> File, it's natural to at least have a comparison method since String.equal is essential to it. Plus, we already had isSameFile. >> >> Best, >> Joe >> >>> To Remi?s point this might dissuade/guide developers from using this method when there are other more efficient techniques available when operating at larger scales. However, it is unfortunately harder that it should be in Java to hash the contents of a file, a byte[] or ByteBuffer, according to some chosen algorithm (or a good default). >>> >>> Paul. From huizhe.wang at oracle.com Tue May 1 21:54:17 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 1 May 2018 14:54:17 -0700 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: References: <5AE2AC3C.4040902@oracle.com> <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> <6648FDC1-A3E0-4E6B-AA24-226550D56F66@oracle.com> <12b66f2e-49d8-ec6b-d0fb-dc310152940b@oracle.com> Message-ID: <516790fc-292d-fced-25d9-e5e6cb16fcd5@oracle.com> Thanks John for the background and detailed information. -Joe On 4/30/2018 6:18 PM, John Rose wrote: > On Apr 30, 2018, at 4:47 PM, Joe Wang > wrote: >> >> Are there real-life use cases? It may be useful for example to check >> if the files have the same header. > > After equality comparison, lexical comparison is a key use case. > By allowing the user to interpret the data around the mismatch, > the comparison can be made sensitive to things like locales. > > As Paul implies, finding a mismatch is the correct operation to build > equality checks on top of, because (a) a mismatch has to be detected > anyway to prove inequality, and (b) giving the location of the mismatch, > instead of throwing it away, unlocks a variety of other operations. > > If you want real-life use cases, look at uses of /usr/bin/cmp in Unix > shell scripts. ?The cmp command is to Unix files what Paul's array > mismatch methods are to Java arrays. ?Here's a man page reference: > > https://docs.oracle.com/cd/E19683-01/816-0210/6m6nb7m6c/index.html > > As with the array mismatch methods, the cmp command allows the > user to specify optional offsets within each file to start comparing, as > well as an optional length to stop comparing after. > > See the file BufferMismatch.java for the (partial) application of these > ideas to NIO buffers. > > I suppose the Java-flavored version of "cmp - file" would be a file > comparator which would take a byte buffer as a second operand, > and return an indication of the location of the mismatch. ?Note that > "cmp - file" compares a computed stream against a stored file. > > I think Paul and I have sketched a natural "sweet spot" for performing > bitwise comparisons on stored data. ?It's up to you how much to implement. > I suggest that, if you don't feel inspired to do it all in one go, > that you > leave room in the code for future expansions (maybe as with > BufferMismatch), and perhaps file a follow-up RFE. > > ? John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue May 1 22:04:14 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 2 May 2018 00:04:14 +0200 (CEST) Subject: Hashing files/bytes Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: References: <5AE2AC3C.4040902@oracle.com> <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> <6648FDC1-A3E0-4E6B-AA24-226550D56F66@oracle.com> <1616266894.329304.1525126997632.JavaMail.zimbra@u-pem.fr> Message-ID: <415279124.573863.1525212254277.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > ?: "Remi Forax" > Cc: "Alan Bateman" , "nio-dev" , "core-libs-dev" > > Envoy?: Mardi 1 Mai 2018 00:37:57 > Objet: Hashing files/bytes Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents > Thanks, better then i expected with the transferTo method we recently added, but > i think we could do even better for the ease of use case of ?give me the hash > of this file contents or these bytes or this byte buffer". yes, it can be a nice addition to java.nio.file.Files and in that case the method that compare content can have reference in its documentation to this new method. > > Paul. R?mi > >> On Apr 30, 2018, at 3:23 PM, Remi Forax wrote: >> >>> >>> To Remi?s point this might dissuade/guide developers from using this method when >>> there are other more efficient techniques available when operating at larger >>> scales. However, it is unfortunately harder that it should be in Java to hash >>> the contents of a file, a byte[] or ByteBuffer, according to some chosen >>> algorithm (or a good default). >> >> it's 6 lines of code >> >> var digest = MessageDigest.getInstance("SHA1"); >> try(var input = Files.newInputStream(Path.of("myfile.txt")); >> var output = new DigestOutputStream(OutputStream.nullOutputStream(), digest)) { >> input.transferTo(output); >> } >> var hash = digest.digest(); >> >> or 3 lines if you don't mind to load the whole file in memory >> >> var digest = MessageDigest.getInstance("SHA1"); >> digest.update(Files.readAllBytes(Path.of("myfile.txt"))); >> var hash = digest.digest(); >> >>> >>> Paul. >> > > R?mi From john.r.rose at oracle.com Wed May 2 05:35:38 2018 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 May 2018 22:35:38 -0700 Subject: Hashing files/bytes Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <415279124.573863.1525212254277.JavaMail.zimbra@u-pem.fr> References: <5AE2AC3C.4040902@oracle.com> <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> <6648FDC1-A3E0-4E6B-AA24-226550D56F66@oracle.com> <1616266894.329304.1525126997632.JavaMail.zimbra@u-pem.fr> <415279124.573863.1525212254277.JavaMail.zimbra@u-pem.fr> Message-ID: Here's another potential stacking: Define an interface ByteSequence, similar to CharSequence, as a zero-copy reference to some stored bytes somewhere. (Give it a long length.) Define bulk methods on it like hash and mismatch and transferTo. Then make File and ByteBuffer implement it. Deal with the cross-product of source and destination types underneath the interface. (Also I want ByteSequence as a way to encapsulate resource data for class files and condy, using zero-copy methods. The types byte[] and String don't scale and require copies.) ? John On May 1, 2018, at 3:04 PM, forax at univ-mlv.fr wrote: > > ----- Mail original ----- >> De: "Paul Sandoz" >> ?: "Remi Forax" >> Cc: "Alan Bateman" , "nio-dev" , "core-libs-dev" >> >> Envoy?: Mardi 1 Mai 2018 00:37:57 >> Objet: Hashing files/bytes Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents > >> Thanks, better then i expected with the transferTo method we recently added, but >> i think we could do even better for the ease of use case of ?give me the hash >> of this file contents or these bytes or this byte buffer". > > yes, it can be a nice addition to java.nio.file.Files and in that case the method that compare content can have reference in its documentation to this new method. > >> >> Paul. > > R?mi > >> >>> On Apr 30, 2018, at 3:23 PM, Remi Forax wrote: >>> >>>> >>>> To Remi?s point this might dissuade/guide developers from using this method when >>>> there are other more efficient techniques available when operating at larger >>>> scales. However, it is unfortunately harder that it should be in Java to hash >>>> the contents of a file, a byte[] or ByteBuffer, according to some chosen >>>> algorithm (or a good default). >>> >>> it's 6 lines of code >>> >>> var digest = MessageDigest.getInstance("SHA1"); >>> try(var input = Files.newInputStream(Path.of("myfile.txt")); >>> var output = new DigestOutputStream(OutputStream.nullOutputStream(), digest)) { >>> input.transferTo(output); >>> } >>> var hash = digest.digest(); >>> >>> or 3 lines if you don't mind to load the whole file in memory >>> >>> var digest = MessageDigest.getInstance("SHA1"); >>> digest.update(Files.readAllBytes(Path.of("myfile.txt"))); >>> var hash = digest.digest(); >>> >>>> >>>> Paul. >>> >>> R?mi From forax at univ-mlv.fr Wed May 2 06:53:21 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 2 May 2018 08:53:21 +0200 (CEST) Subject: Hashing files/bytes Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: References: <5AE2AC3C.4040902@oracle.com> <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> <6648FDC1-A3E0-4E6B-AA24-226550D56F66@oracle.com> <1616266894.329304.1525126997632.JavaMail.zimbra@u-pem.fr> <415279124.573863.1525212254277.JavaMail.zimbra@u-pem.fr> Message-ID: <1469442545.607858.1525244001045.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "John Rose" > ?: "Remi Forax" > Cc: "Paul Sandoz" , "nio-dev" , "core-libs-dev" > > Envoy?: Mercredi 2 Mai 2018 07:35:38 > Objet: Re: Hashing files/bytes Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents > Here's another potential stacking: > > Define an interface ByteSequence, similar to CharSequence, > as a zero-copy reference to some stored bytes somewhere. > (Give it a long length.) Define bulk methods on it like hash > and mismatch and transferTo. Then make File and ByteBuffer > implement it. Deal with the cross-product of source and > destination types underneath the interface. > > (Also I want ByteSequence as a way to encapsulate resource > data for class files and condy, using zero-copy methods. > The types byte[] and String don't scale and require copies.) your ByteSequence is ByteBuffer ! a ByteBuffer can be a mapped file or wrapped a byte array, mismatch is compareTo, transferTo is put(ByteBuffer), and hash should be messageDigest.digest(ByteBuffer) which doesn't exist but should. > > ? John R?mi > > On May 1, 2018, at 3:04 PM, forax at univ-mlv.fr wrote: >> >> ----- Mail original ----- >>> De: "Paul Sandoz" >>> ?: "Remi Forax" >>> Cc: "Alan Bateman" , "nio-dev" >>> , "core-libs-dev" >>> >>> Envoy?: Mardi 1 Mai 2018 00:37:57 >>> Objet: Hashing files/bytes Re: RFR(JDK11/NIO) 8202285: (fs) Add a method >>> to Files for comparing file contents >> >>> Thanks, better then i expected with the transferTo method we recently added, but >>> i think we could do even better for the ease of use case of ?give me the hash >>> of this file contents or these bytes or this byte buffer". >> >> yes, it can be a nice addition to java.nio.file.Files and in that case the >> method that compare content can have reference in its documentation to this new >> method. >> >>> >>> Paul. >> >> R?mi >> >>> >>>> On Apr 30, 2018, at 3:23 PM, Remi Forax wrote: >>>> >>>>> >>>>> To Remi?s point this might dissuade/guide developers from using this method when >>>>> there are other more efficient techniques available when operating at larger >>>>> scales. However, it is unfortunately harder that it should be in Java to hash >>>>> the contents of a file, a byte[] or ByteBuffer, according to some chosen >>>>> algorithm (or a good default). >>>> >>>> it's 6 lines of code >>>> >>>> var digest = MessageDigest.getInstance("SHA1"); >>>> try(var input = Files.newInputStream(Path.of("myfile.txt")); >>>> var output = new DigestOutputStream(OutputStream.nullOutputStream(), digest)) { >>>> input.transferTo(output); >>>> } >>>> var hash = digest.digest(); >>>> >>>> or 3 lines if you don't mind to load the whole file in memory >>>> >>>> var digest = MessageDigest.getInstance("SHA1"); >>>> digest.update(Files.readAllBytes(Path.of("myfile.txt"))); >>>> var hash = digest.digest(); >>>> >>>>> >>>>> Paul. >>>> > >>> R?mi From Alan.Bateman at oracle.com Fri May 4 08:30:05 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 May 2018 09:30:05 +0100 Subject: 8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space In-Reply-To: References: <68f27940-c00c-70e3-43ae-caba5fd7b821@oracle.com> Message-ID: <5c34a51a-d728-7671-bcbd-2b5e2766496b@oracle.com> On 27/04/2018 03:21, Ismael Juma wrote: > Sounds good, we can test the changes. > The changes for this issue are in jdk-11-ea+12 [1]. It would be great if you, or Enrico, could try Kafka with this build. -Alan [1] http://jdk.java.net/11/ From yingqi.lu at intel.com Fri May 4 16:42:21 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 4 May 2018 16:42:21 +0000 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13405A8@ORSMSX113.amr.corp.intel.com> <20180308090350.223764266@eggemoggin.niobe.net> <9ACD5B67AAC5594CB6268234CF29CF9AD1341D16@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13961F3@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139A56A@ORSMSX113.amr.corp.intel.com> <4b993019-3038-5584-67fd-31594afe4420@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139D506@ORSMSX113.amr.corp.intel.com> <75e2d375-0760-20f8-f97e-41a11ecfd364@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> Hi All, The version 3 of the patch is available now at http://cr.openjdk.java.net/~ylu/8195160.03/ In this version, I have changed following items: 1. Added Sockets.openRdmaSelector() function 2. Replaced "changing system-wide SocketImplFactory" with returning Socket(impl). I did the similar change to ServerSocket too. I also moved RdmaSocketImplFactory from jdk.net to rdma.ch. 3. Reduced number the factory methods to 2, openRdmaSocket() and openRdmaServerSocket(). 4. Removed the changes to InetAddress. 5. Removed the methods changed to public in Socket/ServerSocket Please let me know your feedback and comments. Thanks, Lucy >-----Original Message----- >From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Lu, >Yingqi >Sent: Sunday, April 29, 2018 8:27 PM >To: Alan Bateman ; nio-dev at openjdk.java.net >Cc: Viswanathan, Sandhya ; Aundhe, >Shirish ; Kaczmarek, Eric > >Subject: RE: adding rsockets support into JDK > >Great idea!! Thank you Alan for your help! > >I will send the updated patch for review early this week. > >Thanks, >Lucy > >>-----Original Message----- >>From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>Sent: Saturday, April 28, 2018 1:00 AM >>To: Lu, Yingqi ; nio-dev at openjdk.java.net >>Cc: Viswanathan, Sandhya ; Aundhe, >>Shirish ; Kaczmarek, Eric >> >>Subject: Re: adding rsockets support into JDK >> >>On 27/04/2018 18:26, Lu, Yingqi wrote: >>> Hi Alan, >>> >>> I have a question regarding to replace "changing system-wide >>SocketImplFactory" to "returning new Socket(impl)". Is it OK if I >>change >>Socket(impl) constructor from protected to public? I need to call it >>from jdk.net module. >>> >>It doesn't need to be changed as you can call it from an anonymous subclass, >e.g.: >> >>SocketImpl impl = factory.createSocketImpl(); return new Socket(impl) { >>}; >> >>-Alan From eolivelli at gmail.com Thu May 10 14:02:52 2018 From: eolivelli at gmail.com (Enrico Olivelli) Date: Thu, 10 May 2018 14:02:52 +0000 Subject: 8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space In-Reply-To: <5c34a51a-d728-7671-bcbd-2b5e2766496b@oracle.com> References: <68f27940-c00c-70e3-43ae-caba5fd7b821@oracle.com> <5c34a51a-d728-7671-bcbd-2b5e2766496b@oracle.com> Message-ID: I confirm that with latest and greatest build of jdk11 Kafka index files are no more "sparse" Thank you very much ! b.q. I have troubles subscribing to this list, I am able to subscribe and receive mails for other openjdk lists (jigsaw, code-libs..) but apparently I can't subscribe to this list. Any idea ? Enrico Il giorno ven 4 mag 2018 alle ore 10:29 Alan Bateman < Alan.Bateman at oracle.com> ha scritto: > On 27/04/2018 03:21, Ismael Juma wrote: > > Sounds good, we can test the changes. > > > The changes for this issue are in jdk-11-ea+12 [1]. It would be great if > you, or Enrico, could try Kafka with this build. > > -Alan > > [1] http://jdk.java.net/11/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu May 10 23:26:31 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 May 2018 16:26:31 -0700 Subject: 8201407: Files.move throws DirectoryNonEmptyException when moving directory across file system Message-ID: https://bugs.openjdk.java.net/browse/JDK-8201407 On Unix, when attempting to move a non-empty directory to a different file system, Files.move() fails with a DirectoryNotEmptyException when it tries to delete the non-empty source directory after copying the top level directory only. The operative part of the specification of Files.move() is: "When invoked to move a directory that is not empty then the directory is moved if it does not require moving the entries in the directory. For example, renaming a directory on the same FileStore will usually not require moving the entries in the directory. When moving a directory requires that its entries be moved then this method fails (by throwing an IOException).? Although the DirectoryNotEmptyException is an IOException, it is not clearly specified that one will be thrown when attempting to move a non-empty source directory to a different file system. Also this situation is not detected in the code as early as it could be. A partial (no Windows change, no tests) fix is here: http://cr.openjdk.java.net/~bpb/8201407/webrev.00/ If this looks like the correct thing to do, then I will file a CSR, develop an analogous Windows fix, and add tests. Thanks, Brian From Alan.Bateman at oracle.com Fri May 11 08:12:25 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 May 2018 09:12:25 +0100 Subject: 8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space In-Reply-To: References: <68f27940-c00c-70e3-43ae-caba5fd7b821@oracle.com> <5c34a51a-d728-7671-bcbd-2b5e2766496b@oracle.com> Message-ID: On 10/05/2018 15:02, Enrico Olivelli wrote: > I confirm that with latest and greatest build of jdk11 Kafka index > files are no more "sparse" > Thank you very much ! Thanks for checking this (I assume you mean the files continue to be sparse when extended). > > b.q. I have troubles subscribing to this list, I am able to subscribe > and receive mails for other openjdk lists (jigsaw, code-libs..) but > apparently I can't subscribe to this list. Any idea ? Do you use more than one email address? Sometimes people subscribe with one address but send mail to the listing from a different address. Otherwise I don't know what the issue might be, I don't see the address you are currently using on the subscribers list. -Alan From Alan.Bateman at oracle.com Fri May 11 12:18:02 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 May 2018 13:18:02 +0100 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1341D16@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13961F3@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139A56A@ORSMSX113.amr.corp.intel.com> <4b993019-3038-5584-67fd-31594afe4420@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139D506@ORSMSX113.amr.corp.intel.com> <75e2d375-0760-20f8-f97e-41a11ecfd364@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> Message-ID: <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> On 04/05/2018 17:42, Lu, Yingqi wrote: > Hi All, > > The version 3 of the patch is available now at http://cr.openjdk.java.net/~ylu/8195160.03/ > > In this version, I have changed following items: > > 1. Added Sockets.openRdmaSelector() function > > 2. Replaced "changing system-wide SocketImplFactory" with returning Socket(impl). I did the similar change to ServerSocket too. I also moved RdmaSocketImplFactory from jdk.net to rdma.ch. > > 3. Reduced number the factory methods to 2, openRdmaSocket() and openRdmaServerSocket(). > > 4. Removed the changes to InetAddress. > > 5. Removed the methods changed to public in Socket/ServerSocket > > Please let me know your feedback and comments. > I looked through the current version. The API additions to jdk.net.Sockets API look good. The javadoc will need to be fleshed out of course. Did you mean to include jdk.net.RdmaSocketImplFactory in the API? The factory methods can create the RdmaSocketImpl directly so it may not be needed. jdk.net.RdmaSocketOptions looks right. It will of course need javadoc and some refactoring so that hardcoded values aren't in shared code. There are a few changes to the java.net API that will need consideration. Having a protected constructor that takes a SocketImpl looks reasonable on first glance it is consistent with the protected constructor in Socket. The addition of protected setters to SocketImpl may be okay too although not strictly needed as the fd and address fields are protected so they can be set by implementations already. You've changed ServerSocket accept to support the RdmaSocketImpl but I don't think you need that. Instead, the ServerSocket returned by openServerSocket can override the accept method. I think this means you can drop the qualified export of jdk.net to java.base too. I'm a bit uncomfortable with extending SocketChannelImpl and ServerSocketChannelImpl as proposed because it tightly ties the RMDA implementation in jdk.net. It means we can't change anything in say SocketChannelImpl without breaking the RDMA implementation. Given that the RMDA implementations override almost everything then maybe they should just extend SocketChannel directly and we'll need to the duplication as needed. The extending of PollSelectorImpl is probably okay, just needs a comment to poll method to explain what it is protected. libextnet also builds on Solaris so the updates to Lib-jdk.net.gmk will need a few adjustments to ensure that it continues to build (you'll need to add -lrdmacm to LIBS_linux rather than LIBS for example). Are you planning to develop tests for this? We also have the issue how this is going to be tested and maintained over the long term. -Alan From eolivelli at gmail.com Fri May 11 16:23:54 2018 From: eolivelli at gmail.com (Enrico Olivelli) Date: Fri, 11 May 2018 18:23:54 +0200 Subject: 8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space In-Reply-To: References: <68f27940-c00c-70e3-43ae-caba5fd7b821@oracle.com> <5c34a51a-d728-7671-bcbd-2b5e2766496b@oracle.com> Message-ID: Il ven 11 mag 2018, 10:12 Alan Bateman ha scritto: > On 10/05/2018 15:02, Enrico Olivelli wrote: > > I confirm that with latest and greatest build of jdk11 Kafka index > > files are no more "sparse" > > Thank you very much ! > Thanks for checking this (I assume you mean the files continue to be > sparse when extended). > Yes, sorry, now files are 'sparse'. Is any chance to see the fix on 10.x branch ? > > > > > b.q. I have troubles subscribing to this list, I am able to subscribe > > and receive mails for other openjdk lists (jigsaw, code-libs..) but > > apparently I can't subscribe to this list. Any idea ? > Do you use more than one email address? Sometimes people subscribe with > one address but send mail to the listing from a different address. > Otherwise I don't know what the issue might be, I don't see the address > you are currently using on the subscribers list. > I am trying with eolivelli at gmail.com And eolivelli at apache.org This is off-topic, I will eventually start another thread/contact list admin Thank you Enrico > > -Alan > -- -- Enrico Olivelli -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Fri May 11 16:37:41 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 11 May 2018 16:37:41 +0000 Subject: adding rsockets support into JDK In-Reply-To: <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1341D16@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13961F3@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139A56A@ORSMSX113.amr.corp.intel.com> <4b993019-3038-5584-67fd-31594afe4420@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139D506@ORSMSX113.amr.corp.intel.com> <75e2d375-0760-20f8-f97e-41a11ecfd364@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> Hi Alan, Thank you very much for your feedback! I agree that jdk.net.RdmaSocketImplFactory is not necessary anymore. I will remove it in next version. I will remove the inheritance from SocketChannelImpl/ServerSocketChannelImpl, replace them with SocketChannel/ServerSocketChannel. My initial thought was to avoid the code duplication, but I totally agree with you on your concern for future maintenance. I will also make other changes following your suggestions and start to add test cases. I will start from the examples of regular sockets and socket channels and add ones specific to RDMA. Thank you!! Lucy >-----Original Message----- >From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >Sent: Friday, May 11, 2018 5:18 AM >To: Lu, Yingqi ; nio-dev at openjdk.java.net >Cc: Viswanathan, Sandhya ; Aundhe, >Shirish ; Kaczmarek, Eric > >Subject: Re: adding rsockets support into JDK > >On 04/05/2018 17:42, Lu, Yingqi wrote: >> Hi All, >> >> The version 3 of the patch is available now at >> http://cr.openjdk.java.net/~ylu/8195160.03/ >> >> In this version, I have changed following items: >> >> 1. Added Sockets.openRdmaSelector() function >> >> 2. Replaced "changing system-wide SocketImplFactory" with returning >Socket(impl). I did the similar change to ServerSocket too. I also moved >RdmaSocketImplFactory from jdk.net to rdma.ch. >> >> 3. Reduced number the factory methods to 2, openRdmaSocket() and >openRdmaServerSocket(). >> >> 4. Removed the changes to InetAddress. >> >> 5. Removed the methods changed to public in Socket/ServerSocket >> >> Please let me know your feedback and comments. >> >I looked through the current version. > >The API additions to jdk.net.Sockets API look good. The javadoc will need to >be fleshed out of course. > >Did you mean to include jdk.net.RdmaSocketImplFactory in the API? The >factory methods can create the RdmaSocketImpl directly so it may not be >needed. > >jdk.net.RdmaSocketOptions looks right. It will of course need javadoc and >some refactoring so that hardcoded values aren't in shared code. > >There are a few changes to the java.net API that will need consideration. >Having a protected constructor that takes a SocketImpl looks reasonable on >first glance it is consistent with the protected constructor in Socket. > >The addition of protected setters to SocketImpl may be okay too although not >strictly needed as the fd and address fields are protected so they can be set >by implementations already. > >You've changed ServerSocket accept to support the RdmaSocketImpl but I >don't think you need that. Instead, the ServerSocket returned by >openServerSocket can override the accept method. I think this means you can >drop the qualified export of jdk.net to java.base too. > >I'm a bit uncomfortable with extending SocketChannelImpl and >ServerSocketChannelImpl as proposed because it tightly ties the RMDA >implementation in jdk.net. It means we can't change anything in say >SocketChannelImpl without breaking the RDMA implementation. Given that >the RMDA implementations override almost everything then maybe they >should just extend SocketChannel directly and we'll need to the duplication as >needed. > >The extending of PollSelectorImpl is probably okay, just needs a comment to >poll method to explain what it is protected. > >libextnet also builds on Solaris so the updates to Lib-jdk.net.gmk will need a >few adjustments to ensure that it continues to build (you'll need to add - >lrdmacm to LIBS_linux rather than LIBS for example). > >Are you planning to develop tests for this? We also have the issue how this is >going to be tested and maintained over the long term. > >-Alan From Alan.Bateman at oracle.com Fri May 11 19:34:06 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 May 2018 20:34:06 +0100 Subject: Behaviour of SocketChannelImpl.close() in Java11 (ea+12) In-Reply-To: <31B6C8FB-D31F-4A41-84B2-CEC590ED133B@googlemail.com> References: <31B6C8FB-D31F-4A41-84B2-CEC590ED133B@googlemail.com> Message-ID: (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 your thoughts on the behaviour changes: > > 1) SocketChannelImpl.close() will trigger shutdown(?,SHUT_WR) if the > channel is connected before do the actual close(?). > > This is different to earlier version where it was just closed via > close(?). We noticed this because we have a unit test that basically > set SO_LINGER 0 and verifies that the remote peer sees a ECONNRESET > when channel is closed. This is not the case here anymore as the > shutdown will cause an EOF. > I wonder depending on the connection reset is just plain wrong from > our side as its an implementation detail, but at least it was super > surprising to me that a shutdown(?) was called during the close > operation. Especially as shutdownOutput() is exposed directly as well. > > > 2) SocketChannelImpl.close() will not directly close the fd but add it > to a queue that will be processed by the Selector. > > Again this is different to earlier versions and had the effect that > one test failed that expected that the fd is really closed when > close() returns. > If I read this correctly, #1 and #2 are asking about closing a SocketChannel that is registered with a Selector. If registered with a Selector then the channel must be configured non-blocking. I'll start with #2 as closing a SocketChannel registered with a Selector has always delayed releasing the file descriptor until it has been flushed from all Selectors. If the Netty tests are monitoring the file descriptor count (maybe with the management API?) then you shouldn't see a difference. If #2 is about whether the peer sees a graceful close or a TCP reset then the behavior should be the same as older releases too, except when the linger-on-close socket option is enabled, which leads to your question #1. On #1, then one initial thing to point out is that SO_LINGER is only specified for sockets configured in blocking mode. From the javadoc: "This socket option is intended for use with sockets that are configured in blocking mode only. The behavior of the close method when this option is enabled on a non-blocking socket is not defined." You are correct that there is a behavior difference in JDK 11 when enabling this socket option on a SocketChannel configured non-blocking and then closing it when it is registered with one or more Selector. That behavior difference arises because close in JDK 10 (and older) always "pre-closed" (essentially a dup2) the file descriptor whereas JDK 11 does not do this when the channel is configured non-blocking. The two phase close trick is needed for channels in blocking mode, not so for channels configured non-blocking where it has always been very problematic to switch the file descriptor whilst registered with a Selector. As regards the half close / shutdown when registered with a Selector then this is so that the peer detects the connection shutdown. The peer otherwise not observe the shutdown until the channel is flushed from the Selector. I'm in two minds as to whether we should do anything to try to restore "not defined" behavior. We could potentially skip the shutdown when the linger-on-close socket option is enabled. That would at least allow tests that exercise TCP resets to continue to work, assuming the channel is flushed promptly from all Selectors that it is registered with. -Alan From norman.maurer at googlemail.com Fri May 11 18:14:40 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Fri, 11 May 2018 20:14:40 +0200 Subject: Behaviour of SocketChannelImpl.close() in Java11 (ea+12) Message-ID: 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 your thoughts on the behaviour changes: 1) SocketChannelImpl.close() will trigger shutdown(?,SHUT_WR) if the channel is connected before do the actual close(?). This is different to earlier version where it was just closed via close(?). We noticed this because we have a unit test that basically set SO_LINGER 0 and verifies that the remote peer sees a ECONNRESET when channel is closed. This is not the case here anymore as the shutdown will cause an EOF. I wonder depending on the connection reset is just plain wrong from our side as its an implementation detail, but at least it was super surprising to me that a shutdown(?) was called during the close operation. Especially as shutdownOutput() is exposed directly as well. 2) SocketChannelImpl.close() will not directly close the fd but add it to a queue that will be processed by the Selector. Again this is different to earlier versions and had the effect that one test failed that expected that the fd is really closed when close() returns. I worked around these differences via [2] but I wanted to ask if this is expected. Java version: java version "11-ea" 2018-09-25 Java(TM) SE Runtime Environment 18.9 (build 11-ea+12) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+12, mixed mode) [1] http://netty.io [2] https://github.com/netty/netty/pull/7926 -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman.maurer at googlemail.com Fri May 11 19:40:57 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Fri, 11 May 2018 21:40:57 +0200 Subject: Behaviour of SocketChannelImpl.close() in Java11 (ea+12) In-Reply-To: References: <31B6C8FB-D31F-4A41-84B2-CEC590ED133B@googlemail.com> Message-ID: <6C73EF7A-1494-4EF7-A559-662FB8F5A28E@googlemail.com> > On 11. May 2018, at 21:34, Alan Bateman wrote: > > (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 your thoughts on the behaviour changes: >> >> 1) SocketChannelImpl.close() will trigger shutdown(?,SHUT_WR) if the channel is connected before do the actual close(?). >> >> This is different to earlier version where it was just closed via close(?). We noticed this because we have a unit test that basically set SO_LINGER 0 and verifies that the remote peer sees a ECONNRESET when channel is closed. This is not the case here anymore as the shutdown will cause an EOF. >> I wonder depending on the connection reset is just plain wrong from our side as its an implementation detail, but at least it was super surprising to me that a shutdown(?) was called during the close operation. Especially as shutdownOutput() is exposed directly as well. >> >> >> 2) SocketChannelImpl.close() will not directly close the fd but add it to a queue that will be processed by the Selector. >> >> Again this is different to earlier versions and had the effect that one test failed that expected that the fd is really closed when close() returns. >> > If I read this correctly, #1 and #2 are asking about closing a SocketChannel that is registered with a Selector. If registered with a Selector then the channel must be configured non-blocking. You are reading it correctly ? > > I'll start with #2 as closing a SocketChannel registered with a Selector has always delayed releasing the file descriptor until it has been flushed from all Selectors. If the Netty tests are monitoring the file descriptor count (maybe with the management API?) then you shouldn't see a difference. If #2 is about whether the peer sees a graceful close or a TCP reset then the behavior should be the same as older releases too, except when the linger-on-close socket option is enabled, which leads to your question #1. I should have also mentioned that this test uses SO_LINGER 0 and so is also related to 1) as well a bit but not 100 %. The problem basically is that before after we called SocketChannel.close() the write on the peer SocketChannel always failed after the close() call returned which seems to not be the case anymore. > > On #1, then one initial thing to point out is that SO_LINGER is only specified for sockets configured in blocking mode. From the javadoc: > > "This socket option is intended for use with sockets that are configured in blocking mode only. The behavior of the close method when this option is enabled on a non-blocking socket is not defined.? Interesting enough I never noticed this javadoc and just assumed it would work the same way as when I just do it via C, which also works for non-blocking sockets (at least with SO_LINGER 0). > > You are correct that there is a behavior difference in JDK 11 when enabling this socket option on a SocketChannel configured non-blocking and then closing it when it is registered with one or more Selector. That behavior difference arises because close in JDK 10 (and older) always "pre-closed" (essentially a dup2) the file descriptor whereas JDK 11 does not do this when the channel is configured non-blocking. The two phase close trick is needed for channels in blocking mode, not so for channels configured non-blocking where it has always been very problematic to switch the file descriptor whilst registered with a Selector. > > As regards the half close / shutdown when registered with a Selector then this is so that the peer detects the connection shutdown. The peer otherwise not observe the shutdown until the channel is flushed from the Selector. > > I'm in two minds as to whether we should do anything to try to restore "not defined" behavior. We could potentially skip the shutdown when the linger-on-close socket option is enabled. That would at least allow tests that exercise TCP resets to continue to work, assuming the channel is flushed promptly from all Selectors that it is registered with. As the java docs clearly state its ?undefined? for non-blocking (which I never noticed) I am completely happy either way. I was just surprised about the change in behaviour and wanted to bring it up as others may also be surprised. > > -Alan Thanks Norman From Alan.Bateman at oracle.com Sun May 13 07:36:29 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 13 May 2018 08:36:29 +0100 Subject: Behaviour of SocketChannelImpl.close() in Java11 (ea+12) In-Reply-To: <6C73EF7A-1494-4EF7-A559-662FB8F5A28E@googlemail.com> References: <31B6C8FB-D31F-4A41-84B2-CEC590ED133B@googlemail.com> <6C73EF7A-1494-4EF7-A559-662FB8F5A28E@googlemail.com> Message-ID: On 11/05/2018 20:40, Norman Maurer wrote: > : > Interesting enough I never noticed this javadoc and just assumed it would work the same way as when I just do it via C, which also works for non-blocking sockets (at least with SO_LINGER 0). > The awkward case is enabling linger to a value > 0 as that means the underlying close(2) may potentially block. This gets problematic for selection operations that may have to close a lot of sockets (due to close being called on channels registered with the Selector). There was no intention to break the SO_LINGER = 0 case when this code was refactored a few months ago. We can get that working again, at least for cases where the closed channels are promptly flushed from the Selectors that they are registered with. I have changes that I will bring here for review soon. -Alan. From norman.maurer at googlemail.com Sun May 13 07:40:21 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Sun, 13 May 2018 09:40:21 +0200 Subject: Behaviour of SocketChannelImpl.close() in Java11 (ea+12) In-Reply-To: References: <31B6C8FB-D31F-4A41-84B2-CEC590ED133B@googlemail.com> <6C73EF7A-1494-4EF7-A559-662FB8F5A28E@googlemail.com> Message-ID: > Am 13.05.2018 um 09:36 schrieb Alan Bateman : > >> On 11/05/2018 20:40, Norman Maurer wrote: >> : >> Interesting enough I never noticed this javadoc and just assumed it would work the same way as when I just do it via C, which also works for non-blocking sockets (at least with SO_LINGER 0). >> > The awkward case is enabling linger to a value > 0 as that means the underlying close(2) may potentially block. This gets problematic for selection operations that may have to close a lot of sockets (due to close being called on channels registered with the Selector). Agree... we saw this exact problem in Netty when someone used 10 seconds and the tried to close sockets which ended up blocking the EventLoop (IO thread). > > There was no intention to break the SO_LINGER = 0 case when this code was refactored a few months ago. We can get that working again, at least for cases where the closed channels are promptly flushed from the Selectors that they are registered with. I have changes that I will bring here for review soon. Sounds good ?? I will happily review the changes and try out with Netty unit tests. > > -Alan. From Alan.Bateman at oracle.com Sun May 13 07:52:42 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 13 May 2018 08:52:42 +0100 Subject: 8201407: Files.move throws DirectoryNonEmptyException when moving directory across file system In-Reply-To: References: Message-ID: <11d848fb-4a9e-8edd-c60f-8a19acd77e59@oracle.com> On 11/05/2018 00:26, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8201407 > > On Unix, when attempting to move a non-empty directory to a different file system, Files.move() fails with a DirectoryNotEmptyException when it tries to delete the non-empty source directory after copying the top level directory only. The operative part of the specification of Files.move() is: > > "When invoked to move a directory that is not empty then the directory is moved if it does not require moving the entries in the directory. For example, renaming a directory on the same FileStore will usually not require moving the entries in the directory. When moving a directory requires that its entries be moved then this method fails (by throwing an IOException).? > > Although the DirectoryNotEmptyException is an IOException, it is not clearly specified that one will be thrown when attempting to move a non-empty source directory to a different file system. Also this situation is not detected in the code as early as it could be. A partial (no Windows change, no tests) fix is here: > > http://cr.openjdk.java.net/~bpb/8201407/webrev.00/ > > If this looks like the correct thing to do, then I will file a CSR, develop an analogous Windows fix, and add tests. > This subtly changes DirectoryNotEmptyException from an "optional specific exception" to a mandated exception. I think it would be better to just add to the existing @throws DirectoryNotEmptyException as the spec can't guarantee that you can throw this specific exception in all scenarios. As regards whether to attempt to check for entries before creating the target directory then that seems worth exploring. -Alan From Alan.Bateman at oracle.com Sun May 13 08:11:39 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 13 May 2018 09:11:39 +0100 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139A56A@ORSMSX113.amr.corp.intel.com> <4b993019-3038-5584-67fd-31594afe4420@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139D506@ORSMSX113.amr.corp.intel.com> <75e2d375-0760-20f8-f97e-41a11ecfd364@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> Message-ID: <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> On 11/05/2018 17:37, Lu, Yingqi wrote: > Hi Alan, > > Thank you very much for your feedback! > > I agree that jdk.net.RdmaSocketImplFactory is not necessary anymore. I will remove it in next version. > > I will remove the inheritance from SocketChannelImpl/ServerSocketChannelImpl, replace them with SocketChannel/ServerSocketChannel. My initial thought was to avoid the code duplication, but I totally agree with you on your concern for future maintenance. > > I will also make other changes following your suggestions and start to add test cases. I will start from the examples of regular sockets and socket channels and add ones specific to RDMA. Are you still planning to submit a JEP? -Alan From yingqi.lu at intel.com Sun May 13 14:48:21 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Sun, 13 May 2018 14:48:21 +0000 Subject: adding rsockets support into JDK In-Reply-To: <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139A56A@ORSMSX113.amr.corp.intel.com> <4b993019-3038-5584-67fd-31594afe4420@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139D506@ORSMSX113.amr.corp.intel.com> <75e2d375-0760-20f8-f97e-41a11ecfd364@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com>, <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> Message-ID: <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> Yes! Will submit early next week. Thank you for the reminder. Thanks, Lucy Sent from my iPhone > On May 13, 2018, at 1:11 AM, Alan Bateman wrote: > >> On 11/05/2018 17:37, Lu, Yingqi wrote: >> Hi Alan, >> >> Thank you very much for your feedback! >> >> I agree that jdk.net.RdmaSocketImplFactory is not necessary anymore. I will remove it in next version. >> >> I will remove the inheritance from SocketChannelImpl/ServerSocketChannelImpl, replace them with SocketChannel/ServerSocketChannel. My initial thought was to avoid the code duplication, but I totally agree with you on your concern for future maintenance. >> >> I will also make other changes following your suggestions and start to add test cases. I will start from the examples of regular sockets and socket channels and add ones specific to RDMA. > Are you still planning to submit a JEP? > > -Alan From Alan.Bateman at oracle.com Mon May 14 13:09:49 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 May 2018 14:09:49 +0100 Subject: 8203059: (so) Closing a socket channel registered with Selector and with SO_LINGER set to 0 does not reset connection Message-ID: <7da3ad46-b3a3-f080-dec1-c60208f19ea0@oracle.com> This is a follow-up to the "Behaviour of SocketChannelImpl.close() in Java11 ..." thread where it was observed that closing a SocketChannel registered with a Selector does not obey the linger on close interval when enabled. As discussed in that thread, the SO_LINGER socket option is not specified for channels configured non-blocking. At the same time, it can be useful to enable to a value of 0 to force a connection reset. As things stand, closing a socket channel with SO_LINGER enabled will obey the linger value when the channel is not registered with a Selector (it doesn't matter if the channel is configured blocking or non-blocking). It does not obey the linger value when the channel is registered with a Selector - this is because closing a SocketChannel registered with a Selector first shuts down the connection for writing (so that the peer reads EOF). The following patches changes close so that SO_LINGER can be be used force a connection reset for the case that a channel is registered with a Selector and the channel is flushed from the Selector in timely manner. The linger interval > 0 case is too problematic and it can delay selection operations so the change will disable it and avoid selection operations blocking when they deregister closed channels. The test case exercises all the combinations and ensures that the behavior is consistent across all platforms. ??? http://cr.openjdk.java.net/~alanb/8203059/webrev/ -Alan From chris.hegarty at oracle.com Mon May 14 20:37:56 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 May 2018 21:37:56 +0100 Subject: 8203059: (so) Closing a socket channel registered with Selector and with SO_LINGER set to 0 does not reset connection In-Reply-To: <7da3ad46-b3a3-f080-dec1-c60208f19ea0@oracle.com> References: <7da3ad46-b3a3-f080-dec1-c60208f19ea0@oracle.com> Message-ID: > On 14 May 2018, at 14:09, Alan Bateman wrote: > > This is a follow-up to the "Behaviour of SocketChannelImpl.close() in Java11 ..." thread where it was observed that closing a SocketChannel registered with a Selector does not obey the linger on close interval when enabled. > > As discussed in that thread, the SO_LINGER socket option is not specified for channels configured non-blocking. At the same time, it can be useful to enable to a value of 0 to force a connection reset. As things stand, closing a socket channel with SO_LINGER enabled will obey the linger value when the channel is not registered with a Selector (it doesn't matter if the channel is configured blocking or non-blocking). It does not obey the linger value when the channel is registered with a Selector - this is because closing a SocketChannel registered with a Selector first shuts down the connection for writing (so that the peer reads EOF). > > The following patches changes close so that SO_LINGER can be be used force a connection reset for the case that a channel is registered with a Selector and the channel is flushed from the Selector in timely manner. The linger interval > 0 case is too problematic and it can delay selection operations so the change will disable it and avoid selection operations blocking when they deregister closed channels. The test case exercises all the combinations and ensures that the behavior is consistent across all platforms. > http://cr.openjdk.java.net/~alanb/8203059/webrev/ I?ve studied the changes and the surrounding code. Looks good. -Chris From roger.riggs at oracle.com Tue May 15 14:51:39 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 15 May 2018 10:51:39 -0400 Subject: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file In-Reply-To: <7ffaa0de-cbee-0fc7-57b2-44caa39dad47@oracle.com> References: <5AE2AC03.9000705@oracle.com> <1297536212.1989108.1524828579265.JavaMail.zimbra@u-pem.fr> <515d4180-e2b7-48f3-5856-f472cf7892a4@oracle.com> <106042075.1993206.1524829404390.JavaMail.zimbra@u-pem.fr> <499f6815-ae0d-73e6-e606-5f3352c89ba9@oracle.com> <2100883236.2133173.1524858613899.JavaMail.zimbra@u-pem.fr> <7ffaa0de-cbee-0fc7-57b2-44caa39dad47@oracle.com> Message-ID: Hi Joe, et. al. My $.02 on line separators: ?- We should avoid clever tricks trying to solve problems that are infrequent such as cross OS file line operations. ??? Most files will be read/written on a single system so the line separators will be as expected. ?- Have/use APIs that split lines consistently accepting both line separators so developer code can be agnostic to line separators. ??? aka BufferedReader.readLine for developers that are processing the contents *as lines*. ?? Those other methods already exist; if there are any gaps in line oriented processing that's a separate task. ?- These new file methods are defined to handle Charset encoding/decoding and buffering. ??? Since there are other methods to deal with files as lines these methods should not look for or break to lines. ?- Performance: adding code to look for line characters will slow it down and in most cases would have no impact ??? since the line endings will match the system. ?- The strings passed to writeString (CharSequence) should have been constructed using the proper line separators. ??? There are any number of methods that insert the os specific line terminator and its easy to write File.separator as needed. As for the method naming: I'd prefer "writeString" as a familiar term that isn't stretched too far by making the argument be a CharSequence. its fine to call a CharSequence a string (with a lower case s). $.02, Roger On 4/27/18 6:33 PM, Joe Wang wrote: > > > On 4/27/2018 12:50 PM, forax at univ-mlv.fr wrote: >> ----- Mail original ----- >>> De: "Joe Wang" >>> ?: "Remi Forax" , "Alan Bateman" >>> >>> Cc: "nio-dev" , "core-libs-dev" >>> >>> Envoy?: Vendredi 27 Avril 2018 21:21:01 >>> Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for >>> reading/writing a string from/to a file >>> Hi R?mi, Alan, >> Hi Joe, >> >>> I'm not sure we'd want to replace system dependent line separators with >>> '\n'. There are cases as you described where the replacement makes >>> sense. However,? there are other cases too. For example, the purpose is >>> to read, edit a text file and then write it back. If this is on >>> Windows, >>> and if line separators are replaced with '\n', that would cause the >>> resulting file not formatted properly in for example Notepad. There are >>> cases where users write text files on Windows using Java, and only >>> found >>> the lines were not separated in Notepad. >> I agree that why the counterpart of readString() that write the >> string should inserts the platform's line separator. >> BTW, i just found that those methods are not named writeString, or >> writeCharSequence, i think they should. > > While readString() does not modify the original content (e.g. by > replacing the platform's line separator with '\n'), write(String) > won't either, by adding extra characters such as the line separator. > > I would think interfaces shall read along with the parameters. > ??? readString(Path) == read as a String from the specified Path (one > could argue for readToString, readAsString, but we generally omit the > preps) > ??? write(Path, CharSequence) == write the CharSequence to the file, > since CharSequence is already in the method signature as a parameter, > we probably don't want to add that to the name, otherwise it would > read like repeating the word CharSequence. > > It is in a similar situation as write(Path, Iterable) where it was > defined as writeLines(Path, Iterable). > >> >>> Files.write(Path, Iterable) is also specified to terminate each line >>> with the platform's line separator. If readString does the replacement, >>> it would be inconsistent. >> >> Anyway, if we look for consistency the methods writeCharSequence >> should transform the \n in the CharSequence to the platform's line >> separator. >> >> Files.write(Path, Iterable) is is not a counterpart of readString(), >> it's consistent with Files.lines() or Files.readLines() (or >> BufferedReader.readLine()) that all suppress the line separators. >> Anyway, Files.write(path, readString(path)::line) will be consistent >> if you replace the line separators or not because String.line() >> suppresses the line separators. > > readString pairs with write(String), therefore it's more like > Files.write(path, readString(path)) than readString(path)::line. The > use case: > > ??? String s = Files.read(path); > ??? Files.write(path, s.replace("/config/location", "/new/location")); > > would then work as expected. > > These two methods are one-off (open/read/write/close file) operation. > write(String) therefore is not intended for adding/appending multiple > Strings from other operations such as String.line(). If an app needs > to put the result of String.line() or any other processes into a file > using this method, it needs to take care of adding the line separator > itself when necessary. "when necessary" would be a judgement call by > the developer. > > That said, if there's a consensus on the idea of terminating the > string with a line separator, then readString method would need to > strip it off to go with the write method. > >> >>> I would think readString behaves like readAllBytes, that would >>> simply read all content faithfully. >> readString does an interpolation due to the Charset so it's not the >> real content, again, the idea is that developers should not have to >> care about the platform's line separators (they have more important >> things to think). >> >> The other solution is to just not introduce those new methods, after >> all Files.lines().collect(Collectors.joining("\n")) already does the >> job, no ? > > While there are many ways to do it, none is as straight-forward. "Read > (entire) file to String"/"Write String to file" are popular requests > from users. Read to string -> do some String manipulation -> write it > back is such a simple use case, it really needs to be very easy to do > as illustrated in the above code snippet. > > Cheers, > Joe > >> >>> Best, >>> Joe >> regards, >> R?mi >> >>> On 4/27/2018 4:43 AM, forax at univ-mlv.fr wrote: >>>> Hi Alan, >>>> >>>> People do not read the documentation. >>>> So adding something in the documentation about when a method should >>>> be used or >>>> not is never a solution. >>>> >>>> Here the user want a String and provides a charset so you have no >>>> way but to >>>> decode the content to substitute the line separator. >>>> >>>> cheers, >>>> R?mi >>>> >>>> ----- Mail original ----- >>>>> De: "Alan Bateman" >>>>> ?: "Remi Forax" , "Joe Wang" >>>>> >>>>> Cc: "nio-dev" , "core-libs-dev" >>>>> >>>>> Envoy?: Vendredi 27 Avril 2018 13:34:12 >>>>> Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for >>>>> reading/writing a string from/to a file >>>>> On 27/04/2018 12:29, Remi Forax wrote: >>>>>> I think that having a readString that includes OS dependent line >>>>>> separators is a >>>>>> mistake, >>>>>> Java does a great job to try to shield the developer from the >>>>>> kind of things >>>>>> that makes programs behave differently on different platforms. >>>>>> >>>>>> readString should subtitute (\r)?\n to \n otherwise either people >>>>>> will do a call >>>>>> replace() which is less efficient or will learn the lesson the >>>>>> hard way. >>>>>> >>>>>> raw string literal does the same substitution for the same reason. >>>>>> >>>>> Yes, there are several discussion points around this and somewhat >>>>> timely >>>>> with multi-string support. >>>>> >>>>> One thing that I think Joe will need in this API is some note to >>>>> make it >>>>> clearer what the intended usage is (as I think the intention is >>>>> simple >>>>> cases with mostly single lines of text). >>>>> >>>>> -Alan. > From yingqi.lu at intel.com Wed May 16 19:26:47 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Wed, 16 May 2018 19:26:47 +0000 Subject: adding rsockets support into JDK In-Reply-To: <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139A56A@ORSMSX113.amr.corp.intel.com> <4b993019-3038-5584-67fd-31594afe4420@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139D506@ORSMSX113.amr.corp.intel.com> <75e2d375-0760-20f8-f97e-41a11ecfd364@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com>, <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> Hi All, I have just submitted the initial JEP draft at https://bugs.openjdk.java.net/browse/JDK-8203314 and linked it to the bug JDK-8195160. Do I also need to submit a PDF version to jep-submit at openjdk.java.net or jdk-dev email list? Please review the JEP draft and let me know your comments and feedback. Thanks you!! Lucy >-----Original Message----- >From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Lu, >Yingqi >Sent: Sunday, May 13, 2018 7:48 AM >To: Alan Bateman >Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya >; Aundhe, Shirish >; Kaczmarek, Eric >Subject: Re: adding rsockets support into JDK > >Yes! Will submit early next week. Thank you for the reminder. > >Thanks, >Lucy > >Sent from my iPhone > >> On May 13, 2018, at 1:11 AM, Alan Bateman >wrote: >> >>> On 11/05/2018 17:37, Lu, Yingqi wrote: >>> Hi Alan, >>> >>> Thank you very much for your feedback! >>> >>> I agree that jdk.net.RdmaSocketImplFactory is not necessary anymore. I >will remove it in next version. >>> >>> I will remove the inheritance from >SocketChannelImpl/ServerSocketChannelImpl, replace them with >SocketChannel/ServerSocketChannel. My initial thought was to avoid the >code duplication, but I totally agree with you on your concern for future >maintenance. >>> >>> I will also make other changes following your suggestions and start to add >test cases. I will start from the examples of regular sockets and socket >channels and add ones specific to RDMA. >> Are you still planning to submit a JEP? >> >> -Alan From paul.sandoz at oracle.com Wed May 16 23:46:45 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 May 2018 16:46:45 -0700 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139A56A@ORSMSX113.amr.corp.intel.com> <4b993019-3038-5584-67fd-31594afe4420@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139D506@ORSMSX113.amr.corp.intel.com> <75e2d375-0760-20f8-f97e-41a11ecfd364@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> Message-ID: <3839C3A6-F92C-43E7-BB68-772BDABB9278@oracle.com> > On May 16, 2018, at 12:26 PM, Lu, Yingqi wrote: > > Hi All, > > I have just submitted the initial JEP draft at https://bugs.openjdk.java.net/browse/JDK-8203314 and linked it to the bug JDK-8195160. > Great! > Do I also need to submit a PDF version to jep-submit at openjdk.java.net or jdk-dev email list? > When you think the JEP is of suitable draft quality send an email to jdk-dev at openjdk.java.net (e.g. titled Draft JEP: ) to solicit wider comments beyond this list. This is an informal but encouraged polite step to inform the wider community, where further comments can be taken into account, and it will reduce potential surprises for the next formal step of JEP submission. > Please review the JEP draft and let me know your comments and feedback. > I shall do so this week. Thanks, Paul. > Thanks you!! > > Lucy > >> -----Original Message----- >> From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Lu, >> Yingqi >> Sent: Sunday, May 13, 2018 7:48 AM >> To: Alan Bateman <Alan.Bateman at oracle.com> >> Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya >> <sandhya.viswanathan at intel.com>; Aundhe, Shirish >> <shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com> >> Subject: Re: adding rsockets support into JDK >> >> Yes! Will submit early next week. Thank you for the reminder. >> >> Thanks, >> Lucy >> >> Sent from my iPhone >> >>> On May 13, 2018, at 1:11 AM, Alan Bateman <Alan.Bateman at oracle.com> >> wrote: >>> >>>> On 11/05/2018 17:37, Lu, Yingqi wrote: >>>> Hi Alan, >>>> >>>> Thank you very much for your feedback! >>>> >>>> I agree that jdk.net.RdmaSocketImplFactory is not necessary anymore. I >> will remove it in next version. >>>> >>>> I will remove the inheritance from >> SocketChannelImpl/ServerSocketChannelImpl, replace them with >> SocketChannel/ServerSocketChannel. My initial thought was to avoid the >> code duplication, but I totally agree with you on your concern for future >> maintenance. >>>> >>>> I will also make other changes following your suggestions and start to add >> test cases. I will start from the examples of regular sockets and socket >> channels and add ones specific to RDMA. >>> Are you still planning to submit a JEP? >>> >>> -Alan From yingqi.lu at intel.com Thu May 17 04:03:39 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Thu, 17 May 2018 04:03:39 +0000 Subject: adding rsockets support into JDK In-Reply-To: <3839C3A6-F92C-43E7-BB68-772BDABB9278@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <ab2932c7-663a-83d9-7460-56e77f409c17@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139A56A@ORSMSX113.amr.corp.intel.com> <4b993019-3038-5584-67fd-31594afe4420@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139D506@ORSMSX113.amr.corp.intel.com> <75e2d375-0760-20f8-f97e-41a11ecfd364@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <c4844e84-2356-6fc1-9108-edcafe47e0bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <3839C3A6-F92C-43E7-BB68-772BDABB9278@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD14070E3@ORSMSX113.amr.corp.intel.com> Hi Paul, Thank you for your email! Looking forward to your feedback! Thanks, Lucy >-----Original Message----- >From: Paul Sandoz [mailto:paul.sandoz at oracle.com] >Sent: Wednesday, May 16, 2018 4:47 PM >To: Lu, Yingqi <yingqi.lu at intel.com> >Cc: Alan Bateman <Alan.Bateman at oracle.com>; nio-dev at openjdk.java.net; >Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Aundhe, Shirish ><shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com> >Subject: Re: adding rsockets support into JDK > > > >> On May 16, 2018, at 12:26 PM, Lu, Yingqi <yingqi.lu at intel.com> wrote: >> >> Hi All, >> >> I have just submitted the initial JEP draft at >https://bugs.openjdk.java.net/browse/JDK-8203314 and linked it to the bug >JDK-8195160. >> > >Great! > > >> Do I also need to submit a PDF version to jep-submit at openjdk.java.net or >jdk-dev email list? >> > >When you think the JEP is of suitable draft quality send an email to jdk- >dev at openjdk.java.net (e.g. titled Draft JEP: <title>) to solicit wider comments >beyond this list. This is an informal but encouraged polite step to inform the >wider community, where further comments can be taken into account, and it >will reduce potential surprises for the next formal step of JEP submission. > > >> Please review the JEP draft and let me know your comments and feedback. >> > >I shall do so this week. > >Thanks, >Paul. > >> Thanks you!! >> >> Lucy >> >>> -----Original Message----- >>> From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of >>> Lu, Yingqi >>> Sent: Sunday, May 13, 2018 7:48 AM >>> To: Alan Bateman <Alan.Bateman at oracle.com> >>> Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya >>> <sandhya.viswanathan at intel.com>; Aundhe, Shirish >>> <shirish.aundhe at intel.com>; Kaczmarek, Eric >>> <eric.kaczmarek at intel.com> >>> Subject: Re: adding rsockets support into JDK >>> >>> Yes! Will submit early next week. Thank you for the reminder. >>> >>> Thanks, >>> Lucy >>> >>> Sent from my iPhone >>> >>>> On May 13, 2018, at 1:11 AM, Alan Bateman <Alan.Bateman at oracle.com> >>> wrote: >>>> >>>>> On 11/05/2018 17:37, Lu, Yingqi wrote: >>>>> Hi Alan, >>>>> >>>>> Thank you very much for your feedback! >>>>> >>>>> I agree that jdk.net.RdmaSocketImplFactory is not necessary >>>>> anymore. I >>> will remove it in next version. >>>>> >>>>> I will remove the inheritance from >>> SocketChannelImpl/ServerSocketChannelImpl, replace them with >>> SocketChannel/ServerSocketChannel. My initial thought was to avoid >>> the code duplication, but I totally agree with you on your concern >>> for future maintenance. >>>>> >>>>> I will also make other changes following your suggestions and start >>>>> to add >>> test cases. I will start from the examples of regular sockets and >>> socket channels and add ones specific to RDMA. >>>> Are you still planning to submit a JEP? >>>> >>>> -Alan From paul.sandoz at oracle.com Thu May 17 23:09:30 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 May 2018 16:09:30 -0700 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD14070E3@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <ab2932c7-663a-83d9-7460-56e77f409c17@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139A56A@ORSMSX113.amr.corp.intel.com> <4b993019-3038-5584-67fd-31594afe4420@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139D506@ORSMSX113.amr.corp.intel.com> <75e2d375-0760-20f8-f97e-41a11ecfd364@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <c4844e84-2356-6fc1-9108-edcafe47e0bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <3839C3A6-F92C-43E7-BB68-772BDABB9278@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14070E3@ORSMSX113.amr.corp.intel.com> Message-ID: <F8FC46EF-A7D6-4624-BE04-E6E32C63968E@oracle.com> Hi Lucy, For now i will just focus on the Summary and Description as those are the most important. Alan et. al. are more qualified than I to talk about the specifics. I would like to suggest an alternative title: Socket API for Remote Direct Memory Access (RDMA) with the proposed summary: "Enhance the Java Socket API to support Remote Direct Memory Access (RDMA) using the rsocket protocol on the Linux-based platforms." In the Motivation section you could expand the last sentence to: "To improve this, we propose to add rsocket, a protocol over Remote Direct Memory Access (RDMA) that permits high-throughput, low-latency networking.? s/For HPC and.../High Performance Computing (HPC)?/ Paul. > On May 16, 2018, at 9:03 PM, Lu, Yingqi <yingqi.lu at intel.com> wrote: > > Hi Paul, > > Thank you for your email! Looking forward to your feedback! > > Thanks, > Lucy > >> -----Original Message----- >> From: Paul Sandoz [mailto:paul.sandoz at oracle.com] >> Sent: Wednesday, May 16, 2018 4:47 PM >> To: Lu, Yingqi <yingqi.lu at intel.com> >> Cc: Alan Bateman <Alan.Bateman at oracle.com>; nio-dev at openjdk.java.net; >> Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Aundhe, Shirish >> <shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com> >> Subject: Re: adding rsockets support into JDK >> >> >> >>> On May 16, 2018, at 12:26 PM, Lu, Yingqi <yingqi.lu at intel.com> wrote: >>> >>> Hi All, >>> >>> I have just submitted the initial JEP draft at >> https://bugs.openjdk.java.net/browse/JDK-8203314 and linked it to the bug >> JDK-8195160. >>> >> >> Great! >> >> >>> Do I also need to submit a PDF version to jep-submit at openjdk.java.net or >> jdk-dev email list? >>> >> >> When you think the JEP is of suitable draft quality send an email to jdk- >> dev at openjdk.java.net (e.g. titled Draft JEP: <title>) to solicit wider comments >> beyond this list. This is an informal but encouraged polite step to inform the >> wider community, where further comments can be taken into account, and it >> will reduce potential surprises for the next formal step of JEP submission. >> >> >>> Please review the JEP draft and let me know your comments and feedback. >>> >> >> I shall do so this week. >> >> Thanks, >> Paul. >> >>> Thanks you!! >>> >>> Lucy >>> >>>> -----Original Message----- >>>> From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of >>>> Lu, Yingqi >>>> Sent: Sunday, May 13, 2018 7:48 AM >>>> To: Alan Bateman <Alan.Bateman at oracle.com> >>>> Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya >>>> <sandhya.viswanathan at intel.com>; Aundhe, Shirish >>>> <shirish.aundhe at intel.com>; Kaczmarek, Eric >>>> <eric.kaczmarek at intel.com> >>>> Subject: Re: adding rsockets support into JDK >>>> >>>> Yes! Will submit early next week. Thank you for the reminder. >>>> >>>> Thanks, >>>> Lucy >>>> >>>> Sent from my iPhone >>>> >>>>> On May 13, 2018, at 1:11 AM, Alan Bateman <Alan.Bateman at oracle.com> >>>> wrote: >>>>> >>>>>> On 11/05/2018 17:37, Lu, Yingqi wrote: >>>>>> Hi Alan, >>>>>> >>>>>> Thank you very much for your feedback! >>>>>> >>>>>> I agree that jdk.net.RdmaSocketImplFactory is not necessary >>>>>> anymore. I >>>> will remove it in next version. >>>>>> >>>>>> I will remove the inheritance from >>>> SocketChannelImpl/ServerSocketChannelImpl, replace them with >>>> SocketChannel/ServerSocketChannel. My initial thought was to avoid >>>> the code duplication, but I totally agree with you on your concern >>>> for future maintenance. >>>>>> >>>>>> I will also make other changes following your suggestions and start >>>>>> to add >>>> test cases. I will start from the examples of regular sockets and >>>> socket channels and add ones specific to RDMA. >>>>> Are you still planning to submit a JEP? >>>>> >>>>> -Alan > From yingqi.lu at intel.com Thu May 17 23:45:12 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Thu, 17 May 2018 23:45:12 +0000 Subject: adding rsockets support into JDK In-Reply-To: <F8FC46EF-A7D6-4624-BE04-E6E32C63968E@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <ab2932c7-663a-83d9-7460-56e77f409c17@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139A56A@ORSMSX113.amr.corp.intel.com> <4b993019-3038-5584-67fd-31594afe4420@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139D506@ORSMSX113.amr.corp.intel.com> <75e2d375-0760-20f8-f97e-41a11ecfd364@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <c4844e84-2356-6fc1-9108-edcafe47e0bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <3839C3A6-F92C-43E7-BB68-772BDABB9278@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14070E3@ORSMSX113.amr.corp.intel.com> <F8FC46EF-A7D6-4624-BE04-E6E32C63968E@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1408444@ORSMSX113.amr.corp.intel.com> Hi Paul, Thank you very much for your feedback. I will modify accordingly. Thanks, Lucy >-----Original Message----- >From: Paul Sandoz [mailto:paul.sandoz at oracle.com] >Sent: Thursday, May 17, 2018 4:10 PM >To: Lu, Yingqi <yingqi.lu at intel.com> >Cc: Alan Bateman <Alan.Bateman at oracle.com>; nio-dev at openjdk.java.net; >Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Aundhe, Shirish ><shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com> >Subject: Re: adding rsockets support into JDK > >Hi Lucy, > >For now i will just focus on the Summary and Description as those are the >most important. Alan et. al. are more qualified than I to talk about the >specifics. > >I would like to suggest an alternative title: > > Socket API for Remote Direct Memory Access (RDMA) > >with the proposed summary: > >"Enhance the Java Socket API to support Remote Direct Memory Access >(RDMA) using the rsocket protocol on the Linux-based platforms." > >In the Motivation section you could expand the last sentence to: > >"To improve this, we propose to add rsocket, a protocol over Remote Direct >Memory Access (RDMA) that permits high-throughput, low-latency >networking.? > >s/For HPC and.../High Performance Computing (HPC)?/ > >Paul. > > >> On May 16, 2018, at 9:03 PM, Lu, Yingqi <yingqi.lu at intel.com> wrote: >> >> Hi Paul, >> >> Thank you for your email! Looking forward to your feedback! >> >> Thanks, >> Lucy >> >>> -----Original Message----- >>> From: Paul Sandoz [mailto:paul.sandoz at oracle.com] >>> Sent: Wednesday, May 16, 2018 4:47 PM >>> To: Lu, Yingqi <yingqi.lu at intel.com> >>> Cc: Alan Bateman <Alan.Bateman at oracle.com>; nio- >dev at openjdk.java.net; >>> Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Aundhe, >Shirish >>> <shirish.aundhe at intel.com>; Kaczmarek, Eric >>> <eric.kaczmarek at intel.com> >>> Subject: Re: adding rsockets support into JDK >>> >>> >>> >>>> On May 16, 2018, at 12:26 PM, Lu, Yingqi <yingqi.lu at intel.com> wrote: >>>> >>>> Hi All, >>>> >>>> I have just submitted the initial JEP draft at >>> https://bugs.openjdk.java.net/browse/JDK-8203314 and linked it to the >>> bug JDK-8195160. >>>> >>> >>> Great! >>> >>> >>>> Do I also need to submit a PDF version to >>>> jep-submit at openjdk.java.net or >>> jdk-dev email list? >>>> >>> >>> When you think the JEP is of suitable draft quality send an email to >>> jdk- dev at openjdk.java.net (e.g. titled Draft JEP: <title>) to solicit >>> wider comments beyond this list. This is an informal but encouraged >>> polite step to inform the wider community, where further comments can >>> be taken into account, and it will reduce potential surprises for the next >formal step of JEP submission. >>> >>> >>>> Please review the JEP draft and let me know your comments and >feedback. >>>> >>> >>> I shall do so this week. >>> >>> Thanks, >>> Paul. >>> >>>> Thanks you!! >>>> >>>> Lucy >>>> >>>>> -----Original Message----- >>>>> From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf >>>>> Of Lu, Yingqi >>>>> Sent: Sunday, May 13, 2018 7:48 AM >>>>> To: Alan Bateman <Alan.Bateman at oracle.com> >>>>> Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya >>>>> <sandhya.viswanathan at intel.com>; Aundhe, Shirish >>>>> <shirish.aundhe at intel.com>; Kaczmarek, Eric >>>>> <eric.kaczmarek at intel.com> >>>>> Subject: Re: adding rsockets support into JDK >>>>> >>>>> Yes! Will submit early next week. Thank you for the reminder. >>>>> >>>>> Thanks, >>>>> Lucy >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On May 13, 2018, at 1:11 AM, Alan Bateman >>>>>> <Alan.Bateman at oracle.com> >>>>> wrote: >>>>>> >>>>>>> On 11/05/2018 17:37, Lu, Yingqi wrote: >>>>>>> Hi Alan, >>>>>>> >>>>>>> Thank you very much for your feedback! >>>>>>> >>>>>>> I agree that jdk.net.RdmaSocketImplFactory is not necessary >>>>>>> anymore. I >>>>> will remove it in next version. >>>>>>> >>>>>>> I will remove the inheritance from >>>>> SocketChannelImpl/ServerSocketChannelImpl, replace them with >>>>> SocketChannel/ServerSocketChannel. My initial thought was to avoid >>>>> the code duplication, but I totally agree with you on your concern >>>>> for future maintenance. >>>>>>> >>>>>>> I will also make other changes following your suggestions and >>>>>>> start to add >>>>> test cases. I will start from the examples of regular sockets and >>>>> socket channels and add ones specific to RDMA. >>>>>> Are you still planning to submit a JEP? >>>>>> >>>>>> -Alan >> From Alan.Bateman at oracle.com Fri May 18 07:10:29 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 May 2018 08:10:29 +0100 Subject: Behaviour of SocketChannelImpl.close() in Java11 (ea+12) In-Reply-To: <A3C33ED3-3452-4738-89DA-3A8204B523F1@googlemail.com> References: <31B6C8FB-D31F-4A41-84B2-CEC590ED133B@googlemail.com> <f6effa3c-814a-1e51-b240-49f1ece047af@oracle.com> <6C73EF7A-1494-4EF7-A559-662FB8F5A28E@googlemail.com> <d1868e6d-8680-b2d2-17ff-a33b708c6818@oracle.com> <A3C33ED3-3452-4738-89DA-3A8204B523F1@googlemail.com> Message-ID: <28e24f6b-d7e9-9e19-c98f-09c12b2c22df@oracle.com> On 13/05/2018 08:40, Norman Maurer wrote: > : >> There was no intention to break the SO_LINGER = 0 case when this code was refactored a few months ago. We can get that working again, at least for cases where the closed channels are promptly flushed from the Selectors that they are registered with. I have changes that I will bring here for review soon. > Sounds good ?? I will happily review the changes and try out with Netty unit tests. > > That change made it into jdk-11-ea+14 so it would good if you could try it out [1]. So as discussed, if the SocketChannel has SO_LINGER enabled to a value of 0 and you close it while registered with one or more Selectors then the peer should see a "connection reset" once the channel has been flushed from all Selectors. -Alan. [1] http://jdk.java.net/11/ From norman.maurer at googlemail.com Fri May 18 07:41:50 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Fri, 18 May 2018 09:41:50 +0200 Subject: Behaviour of SocketChannelImpl.close() in Java11 (ea+12) In-Reply-To: <28e24f6b-d7e9-9e19-c98f-09c12b2c22df@oracle.com> References: <31B6C8FB-D31F-4A41-84B2-CEC590ED133B@googlemail.com> <f6effa3c-814a-1e51-b240-49f1ece047af@oracle.com> <6C73EF7A-1494-4EF7-A559-662FB8F5A28E@googlemail.com> <d1868e6d-8680-b2d2-17ff-a33b708c6818@oracle.com> <A3C33ED3-3452-4738-89DA-3A8204B523F1@googlemail.com> <28e24f6b-d7e9-9e19-c98f-09c12b2c22df@oracle.com> Message-ID: <A82F279D-AFDC-4C0B-A7F5-73047AEC42F4@googlemail.com> > On 18. May 2018, at 09:10, Alan Bateman <Alan.Bateman at oracle.com> wrote: > > On 13/05/2018 08:40, Norman Maurer wrote: >> : >>> There was no intention to break the SO_LINGER = 0 case when this code was refactored a few months ago. We can get that working again, at least for cases where the closed channels are promptly flushed from the Selectors that they are registered with. I have changes that I will bring here for review soon. >> Sounds good ?? I will happily review the changes and try out with Netty unit tests. >> >> > That change made it into jdk-11-ea+14 so it would good if you could try it out [1]. So as discussed, if the SocketChannel has SO_LINGER enabled to a value of 0 and you close it while registered with one or more Selectors then the peer should see a "connection reset" once the channel has been flushed from all Selectors. > > -Alan. > > [1] http://jdk.java.net/11/ <http://jdk.java.net/11/> Thanks Alan? I just downloaded the latest release and tested it without test case in netty[1] . All works again as ?expected?, great work and thanks for the quick turnaround. Bye Norman [1] https://github.com/netty/netty/pull/7951 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180518/2b2c71ef/attachment-0001.html> From Alan.Bateman at oracle.com Fri May 18 14:19:47 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 May 2018 15:19:47 +0100 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139D506@ORSMSX113.amr.corp.intel.com> <75e2d375-0760-20f8-f97e-41a11ecfd364@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <c4844e84-2356-6fc1-9108-edcafe47e0bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> Message-ID: <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> On 16/05/2018 20:26, Lu, Yingqi wrote: > Hi All, > > I have just submitted the initial JEP draft at https://bugs.openjdk.java.net/browse/JDK-8203314 and linked it to the bug JDK-8195160. > > Do I also need to submit a PDF version to jep-submit at openjdk.java.net or jdk-dev email list? > > Please review the JEP draft and let me know your comments and feedback. > I agree with Paul that it would be good to get "RDMA" into the title and summary. What would you think about dropping the "Non-public classes" sections and the class diagrams from the Description? That will reduce the Description significantly and make it easier for readers to see that the proposal is to expose the support as factory methods in jdk.net.Sockets. I think the Testing section should make it clear that test requires special hardware. The Alternative section looks good, just change "JDK1.7" to "JDK 7". Risks and Assumptions #3 - I think this can be expanded a bit to say that SocketChannels to RDMA sockets cannot be multiplexed with other selectable channels. -Alan. From yingqi.lu at intel.com Fri May 18 16:06:27 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 18 May 2018 16:06:27 +0000 Subject: adding rsockets support into JDK In-Reply-To: <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD139D506@ORSMSX113.amr.corp.intel.com> <75e2d375-0760-20f8-f97e-41a11ecfd364@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <c4844e84-2356-6fc1-9108-edcafe47e0bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> Thank you for your feedback, Alan! I will modify accordingly, update the JEP online and send a copy to jdk-dev for broader review. Thanks, Lucy >-----Original Message----- >From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >Sent: Friday, May 18, 2018 7:20 AM >To: Lu, Yingqi <yingqi.lu at intel.com> >Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya ><sandhya.viswanathan at intel.com>; Aundhe, Shirish ><shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com> >Subject: Re: adding rsockets support into JDK > >On 16/05/2018 20:26, Lu, Yingqi wrote: >> Hi All, >> >> I have just submitted the initial JEP draft at >https://bugs.openjdk.java.net/browse/JDK-8203314 and linked it to the bug >JDK-8195160. >> >> Do I also need to submit a PDF version to jep-submit at openjdk.java.net or >jdk-dev email list? >> >> Please review the JEP draft and let me know your comments and feedback. >> >I agree with Paul that it would be good to get "RDMA" into the title and >summary. > >What would you think about dropping the "Non-public classes" sections and >the class diagrams from the Description? That will reduce the Description >significantly and make it easier for readers to see that the proposal is to >expose the support as factory methods in jdk.net.Sockets. > >I think the Testing section should make it clear that test requires special >hardware. > >The Alternative section looks good, just change "JDK1.7" to "JDK 7". > >Risks and Assumptions #3 - I think this can be expanded a bit to say that >SocketChannels to RDMA sockets cannot be multiplexed with other selectable >channels. > >-Alan. From chris.hegarty at oracle.com Fri May 18 16:26:32 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 18 May 2018 17:26:32 +0100 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <c4844e84-2356-6fc1-9108-edcafe47e0bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> Message-ID: <f4198ff8-73d3-5fb8-23d1-c63dbe96d962@oracle.com> In addition to the comments so far ... 1) I know that the scope of the JEP is JDK, but it would be clearer once "Non-public classes" is removed, to rename "Public APIs" to "JDK-specific API/classes". 2) As for the title, maybe: "Socket *factory* for Remote Direct Memory Access (RDMA) to make it clear that it is not a new Socket API. -Chris. On 18/05/18 17:06, Lu, Yingqi wrote: > Thank you for your feedback, Alan! > > I will modify accordingly, update the JEP online and send a copy to jdk-dev for broader review. > > Thanks, > Lucy > >> -----Original Message----- >> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >> Sent: Friday, May 18, 2018 7:20 AM >> To: Lu, Yingqi <yingqi.lu at intel.com> >> Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya >> <sandhya.viswanathan at intel.com>; Aundhe, Shirish >> <shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com> >> Subject: Re: adding rsockets support into JDK >> >> On 16/05/2018 20:26, Lu, Yingqi wrote: >>> Hi All, >>> >>> I have just submitted the initial JEP draft at >> https://bugs.openjdk.java.net/browse/JDK-8203314 and linked it to the bug >> JDK-8195160. >>> >>> Do I also need to submit a PDF version to jep-submit at openjdk.java.net or >> jdk-dev email list? >>> >>> Please review the JEP draft and let me know your comments and feedback. >>> >> I agree with Paul that it would be good to get "RDMA" into the title and >> summary. >> >> What would you think about dropping the "Non-public classes" sections and >> the class diagrams from the Description? That will reduce the Description >> significantly and make it easier for readers to see that the proposal is to >> expose the support as factory methods in jdk.net.Sockets. >> >> I think the Testing section should make it clear that test requires special >> hardware. >> >> The Alternative section looks good, just change "JDK1.7" to "JDK 7". >> >> Risks and Assumptions #3 - I think this can be expanded a bit to say that >> SocketChannels to RDMA sockets cannot be multiplexed with other selectable >> channels. >> >> -Alan. From yingqi.lu at intel.com Fri May 18 17:42:45 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 18 May 2018 17:42:45 +0000 Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1409855@ORSMSX113.amr.corp.intel.com> Hi All, Attached JEP draft is for bug 8195160 https://bugs.openjdk.java.net/browse/JDK-8195160. Please review it and let us know your feedback. This effort is to enhance the Java Socket API to support Remote Direct Memory Access (RDMA) using the rsocket protocol on the Linux-based platforms. Thank you for your help! Lucy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180518/85783126/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: JEP-8195160-v1.pdf Type: application/pdf Size: 88119 bytes Desc: JEP-8195160-v1.pdf URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180518/85783126/JEP-8195160-v1-0001.pdf> From yingqi.lu at intel.com Fri May 18 18:16:57 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 18 May 2018 18:16:57 +0000 Subject: adding rsockets support into JDK In-Reply-To: <f4198ff8-73d3-5fb8-23d1-c63dbe96d962@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <c4844e84-2356-6fc1-9108-edcafe47e0bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> <f4198ff8-73d3-5fb8-23d1-c63dbe96d962@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1409AA0@ORSMSX113.amr.corp.intel.com> Thank you Chris for your feedback. I already modify accordingly to https://bugs.openjdk.java.net/browse/JDK-8203434 Thanks, Lucy >-----Original Message----- >From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >Sent: Friday, May 18, 2018 9:27 AM >To: Lu, Yingqi <yingqi.lu at intel.com> >Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya ><sandhya.viswanathan at intel.com>; Aundhe, Shirish ><shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com> >Subject: Re: adding rsockets support into JDK > >In addition to the comments so far ... > >1) I know that the scope of the JEP is JDK, but it would be clearer > once "Non-public classes" is removed, to rename "Public APIs" to > "JDK-specific API/classes". > >2) As for the title, maybe: > "Socket *factory* for Remote Direct Memory Access (RDMA) > > to make it clear that it is not a new Socket API. > >-Chris. > >On 18/05/18 17:06, Lu, Yingqi wrote: >> Thank you for your feedback, Alan! >> >> I will modify accordingly, update the JEP online and send a copy to jdk-dev >for broader review. >> >> Thanks, >> Lucy >> >>> -----Original Message----- >>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>> Sent: Friday, May 18, 2018 7:20 AM >>> To: Lu, Yingqi <yingqi.lu at intel.com> >>> Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya >>> <sandhya.viswanathan at intel.com>; Aundhe, Shirish >>> <shirish.aundhe at intel.com>; Kaczmarek, Eric >>> <eric.kaczmarek at intel.com> >>> Subject: Re: adding rsockets support into JDK >>> >>> On 16/05/2018 20:26, Lu, Yingqi wrote: >>>> Hi All, >>>> >>>> I have just submitted the initial JEP draft at >>> https://bugs.openjdk.java.net/browse/JDK-8203314 and linked it to the >>> bug JDK-8195160. >>>> >>>> Do I also need to submit a PDF version to >>>> jep-submit at openjdk.java.net or >>> jdk-dev email list? >>>> >>>> Please review the JEP draft and let me know your comments and >feedback. >>>> >>> I agree with Paul that it would be good to get "RDMA" into the title >>> and summary. >>> >>> What would you think about dropping the "Non-public classes" sections >>> and the class diagrams from the Description? That will reduce the >>> Description significantly and make it easier for readers to see that >>> the proposal is to expose the support as factory methods in >jdk.net.Sockets. >>> >>> I think the Testing section should make it clear that test requires >>> special hardware. >>> >>> The Alternative section looks good, just change "JDK1.7" to "JDK 7". >>> >>> Risks and Assumptions #3 - I think this can be expanded a bit to say >>> that SocketChannels to RDMA sockets cannot be multiplexed with other >>> selectable channels. >>> >>> -Alan. From yingqi.lu at intel.com Fri May 18 18:21:54 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 18 May 2018 18:21:54 +0000 Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1409AF5@ORSMSX113.amr.corp.intel.com> Hi All, We just submitted a JEP draft https://bugs.openjdk.java.net/browse/JDK-8203434. The proposal is to enhance the Java Socket API to support Remote Direct Memory Access (RDMA) using the rsocket protocol on the Linux-based platforms. Please review it and let us know your feedback. Thank you very much for your help! Thanks, Lucy From: Lu, Yingqi Sent: Friday, May 18, 2018 10:43 AM To: 'jdk-dev at openjdk.java.net' <jdk-dev at openjdk.java.net> Cc: nio-dev at openjdk.java.net; Lu, Yingqi (yingqi.lu at intel.com) <yingqi.lu at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com>; Aundhe, Shirish <shirish.aundhe at intel.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; 'Alan Bateman' <Alan.Bateman at oracle.com>; 'Paul Sandoz' <paul.sandoz at oracle.com> Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) Hi All, Attached JEP draft is for bug 8195160 https://bugs.openjdk.java.net/browse/JDK-8195160. Please review it and let us know your feedback. This effort is to enhance the Java Socket API to support Remote Direct Memory Access (RDMA) using the rsocket protocol on the Linux-based platforms. Thank you for your help! Lucy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180518/73b058b4/attachment.html> From yingqi.lu at intel.com Fri May 18 18:28:14 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 18 May 2018 18:28:14 +0000 Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) In-Reply-To: <c0a5ab99-7182-fc9b-cedc-9a6c617e9b78@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD1409855@ORSMSX113.amr.corp.intel.com> <c0a5ab99-7182-fc9b-cedc-9a6c617e9b78@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1409BF2@ORSMSX113.amr.corp.intel.com> Yes, you are right. Thank you for pointing it out! I found out the attachment cannot be posted on the mailing list, then I sent a follow-up email with the link just seconds ago. I am new to this list :-) Thanks, Lucy >-----Original Message----- >From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >Sent: Friday, May 18, 2018 11:25 AM >To: Lu, Yingqi <yingqi.lu at intel.com>; jdk-dev at openjdk.java.net >Cc: Aundhe, Shirish <shirish.aundhe at intel.com>; nio-dev at openjdk.java.net; >Kaczmarek, Eric <eric.kaczmarek at intel.com> >Subject: Re: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) > >Unfortunately, the attachment was stripped. > >I guess you are talking about the following: > https://bugs.openjdk.java.net/browse/JDK-8203434 > >Best regards, >Vladimir Ivanov > >On 5/18/18 10:42, Lu, Yingqi wrote: >> Hi All, >> >> Attached JEP draft is for bug 8195160 >https://bugs.openjdk.java.net/browse/JDK-8195160. Please review it and let >us know your feedback. This effort is to enhance the Java Socket API to >support Remote Direct Memory Access (RDMA) using the rsocket protocol on >the Linux-based platforms. >> >> Thank you for your help! >> Lucy >> >> From chris.hegarty at oracle.com Mon May 21 10:41:31 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 May 2018 11:41:31 +0100 Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD1409AF5@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD1409AF5@ORSMSX113.amr.corp.intel.com> Message-ID: <d8f916bd-4278-b36b-f6ac-fb0ff889ba22@oracle.com> Hi Lucy, On 18/05/18 19:21, Lu, Yingqi wrote: > Hi All, > > We just submitted a JEP draft > https://bugs.openjdk.java.net/browse/JDK-8203434. ?The proposal is to > enhance the Java Socket API to support Remote Direct Memory Access > (RDMA) using the rsocket protocol on the Linux-based platforms. This latest version looks very good. Just a few minor minor comments that I did not noticed before. 1) What is the behavior on platforms that do not support RDMA? For example, will jdk.net.Sockets::openRdmaSocketChannel throw UnsupportedOperationException? If so, then maybe make that clear in the API sketch in the description. 2) Links to external references seem to have been inadvertently dropped. Prefer markdown links, e.g. ... form [Wikipedia][wikirdma] ... [wikirdma]: https://en.wikipedia.org/wiki/Remote_direct_memory_access -Chris. From Alan.Bateman at oracle.com Mon May 21 10:44:45 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 May 2018 11:44:45 +0100 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <c4844e84-2356-6fc1-9108-edcafe47e0bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> Message-ID: <78430e93-cd5f-13a5-363a-12f0c59e0405@oracle.com> On 18/05/2018 17:06, Lu, Yingqi wrote: > Thank you for your feedback, Alan! > > I will modify accordingly, update the JEP online and send a copy to jdk-dev for broader review. > I read through the updated JEP (in JDK-8203434) and it reads well now. One suggestion is to split the Description so that the API is in its own section after the Description, and before Testing. That would give you a place to explain that the feature is platform specific / non-standard so the proposal is to add the API to the jdk.net module which is where JDK-specific networking features are exposed. The text you have after "Below is the list of proposed public APIs" can follow. One other thing is Risk/Assumption #2 where -Djava.net.preferIPv4Stack=true is needed. We updated the implementation in JDK 7 to allow for mixing of IPv4 and IPv6 sockets in the same VM and I think you should be able to make use of that and avoid needing to force all sockets be IPv4 sockets. The example to look at is DatagramChannelImpl as you can create a DatagramChannel to an IPv4-only socket. In the RDMA SocketChannel/ServerSocketChannel implementations then you should be able to specify the protocol family to connect/accept. You don't need to do this in a first version of course but I think addressing this point will make it a lot more usable. -Alan. From david.lloyd at redhat.com Mon May 21 13:44:22 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 21 May 2018 08:44:22 -0500 Subject: Reimplementing sun.nio.ch.WindowsSelectorImpl using WSAEventSelect and WSAWaitForMultipleEvents instead of a wakeup socket In-Reply-To: <DM6PR15MB22818C9202C581BEC3336A7F9D970@DM6PR15MB2281.namprd15.prod.outlook.com> References: <DM6PR15MB22818C9202C581BEC3336A7F9D970@DM6PR15MB2281.namprd15.prod.outlook.com> Message-ID: <CANghgrQt_8dMc8NKQLHqZ2qse=iZAR-XGwQ0Dh517B4a5Hij4g@mail.gmail.com> The correct list is nio-dev at openjdk.java.net, which I am forwarding this message to. This sounds interesting though. On Fri, May 18, 2018 at 10:23 PM, John Platts <john_platts at hotmail.com> wrote: > The need to allocate a wakeup socket can be eliminated in sun.nio.ch.WindowsSelectorImpl on Windows platforms by reimplementing sun.nio.ch.WindowsSelectorImpl to use the WSAEventSelect and WSAWaitForMultipleEvents APIs introduced in Windows Vista. If WSAEventSelect and WSAWaitForMultipleEvents are used, a wakeup can be done by simply signaling the wakeup event by calling WSASetEvent. > > Here is how to do a select using WSAEventSelect and WSAWaitForMultipleEvents on Windows platforms: > 1. Allocate events for selection and wakeup by calling the WSACreateEvent() function. > 2. Perform a select operation by calling WSAEventSelect method, passing in the event object used for selection. > 3. Call the WSAWaitForMultipleEvents function to wait until one of the events is signaled. > 4. For the remaining events, call WSAWaitForMultipleEvents with a timeout of 0 to check if the event is signaled. > 5. For each of the selection events that are signaled, call the WSAEnumNetworkEvents method to check if the socket is ready for accept, connect, read, or write operations. > 6. To cancel selection, call WSAEventSelect with 0 passed into the lNetworkEvents argument (the third argument). > 7. Free the events allocated by the WSACreateEvent() function by calling the WSACloseEvent() function. -- - DML From yingqi.lu at intel.com Mon May 21 15:36:40 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Mon, 21 May 2018 15:36:40 +0000 Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) In-Reply-To: <d8f916bd-4278-b36b-f6ac-fb0ff889ba22@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD1409AF5@ORSMSX113.amr.corp.intel.com> <d8f916bd-4278-b36b-f6ac-fb0ff889ba22@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD140CE19@ORSMSX113.amr.corp.intel.com> Hi Chris, Thank you for the feedback. Yes, on the platform that does not support rsocket, UOE is thrown. I will make it clear in the document. I will modify the reference links too. Thanks, Lucy >-----Original Message----- >From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >Sent: Monday, May 21, 2018 3:42 AM >To: Lu, Yingqi <yingqi.lu at intel.com>; jdk-dev at openjdk.java.net >Cc: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Aundhe, >Shirish <shirish.aundhe at intel.com>; nio-dev at openjdk.java.net; Kaczmarek, >Eric <eric.kaczmarek at intel.com> >Subject: Re: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) > >Hi Lucy, > >On 18/05/18 19:21, Lu, Yingqi wrote: >> Hi All, >> >> We just submitted a JEP draft >> https://bugs.openjdk.java.net/browse/JDK-8203434. ?The proposal is to >> enhance the Java Socket API to support Remote Direct Memory Access >> (RDMA) using the rsocket protocol on the Linux-based platforms. > >This latest version looks very good. Just a few minor minor comments that I >did not noticed before. > >1) What is the behavior on platforms that do not support RDMA? > For example, will jdk.net.Sockets::openRdmaSocketChannel > throw UnsupportedOperationException? If so, then maybe make > that clear in the API sketch in the description. > >2) Links to external references seem to have been inadvertently > dropped. Prefer markdown links, e.g. > > ... form [Wikipedia][wikirdma] ... > > [wikirdma]: https://en.wikipedia.org/wiki/Remote_direct_memory_access > >-Chris. From yingqi.lu at intel.com Mon May 21 15:51:11 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Mon, 21 May 2018 15:51:11 +0000 Subject: adding rsockets support into JDK In-Reply-To: <78430e93-cd5f-13a5-363a-12f0c59e0405@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <c4844e84-2356-6fc1-9108-edcafe47e0bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> <78430e93-cd5f-13a5-363a-12f0c59e0405@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD140CEB6@ORSMSX113.amr.corp.intel.com> Hi Alan, On the JEP, I will merge your feedback and Chris's feedback into the document today. Since this is my first time drafting a JEP, what is the next step I need to work on besides the webrev? On the patch, I will follow the example of DatagramChannelImpl connect/accept for RDMA based channels and modify the code in the next revision. Thank you! Lucy >-----Original Message----- >From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >Sent: Monday, May 21, 2018 3:45 AM >To: Lu, Yingqi <yingqi.lu at intel.com> >Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya ><sandhya.viswanathan at intel.com>; Aundhe, Shirish ><shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com> >Subject: Re: adding rsockets support into JDK > >On 18/05/2018 17:06, Lu, Yingqi wrote: >> Thank you for your feedback, Alan! >> >> I will modify accordingly, update the JEP online and send a copy to jdk-dev >for broader review. >> >I read through the updated JEP (in JDK-8203434) and it reads well now. > >One suggestion is to split the Description so that the API is in its own section >after the Description, and before Testing. That would give you a place to >explain that the feature is platform specific / non-standard so the proposal is >to add the API to the jdk.net module which is where JDK-specific networking >features are exposed. The text you have after "Below is the list of proposed >public APIs" can follow. > >One other thing is Risk/Assumption #2 where - >Djava.net.preferIPv4Stack=true is needed. We updated the implementation >in JDK 7 to allow for mixing of IPv4 and IPv6 sockets in the same VM and I think >you should be able to make use of that and avoid needing to force all sockets >be IPv4 sockets. The example to look at is DatagramChannelImpl as you can >create a DatagramChannel to an IPv4-only socket. In the RDMA >SocketChannel/ServerSocketChannel implementations then you should be >able to specify the protocol family to connect/accept. You don't need to do >this in a first version of course but I think addressing this point will make it a lot >more usable. > >-Alan. From mlists at juma.me.uk Mon May 21 21:56:43 2018 From: mlists at juma.me.uk (Ismael Juma) Date: Mon, 21 May 2018 14:56:43 -0700 Subject: 8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space In-Reply-To: <CACcefgfouwuhNepB4-XGGxoUJ=A1-pWWc-sdqQfZKEZLS+gJhw@mail.gmail.com> References: <e4a77f6f-841e-b36b-2c02-cae27b332550@oracle.com> <CAD5tkZYCn19dBwkcOfmv1GtAWVU9NewQV0SDW-8O15hUyZbDPg@mail.gmail.com> <CAD5tkZYTSgJry7PDQj5MYUzRMKDETFrPDh0z8ZFm3mHQinsbbw@mail.gmail.com> <68f27940-c00c-70e3-43ae-caba5fd7b821@oracle.com> <CAD5tkZa__byBGdBNR_HdUff3zoD61E5w-TkeN5g8pPRk4ON3rw@mail.gmail.com> <5c34a51a-d728-7671-bcbd-2b5e2766496b@oracle.com> <CACcefgfouwuhNepB4-XGGxoUJ=A1-pWWc-sdqQfZKEZLS+gJhw@mail.gmail.com> Message-ID: <CAD5tkZYYnAH=vaq2A_GWSVyjB1-WGM5yfWcg=4KuLNWGgR+gjg@mail.gmail.com> Any thoughts on a backport to Java 8? Java 10 would be nice to have, but Java 11 is not far away and I don't expect many users to stick with Java 10 for long given the update policy. However, many users will stick to Java 8 for a long time and it would be good to restore the behaviour there. Ismael On Thu, May 10, 2018 at 7:03 AM Enrico Olivelli <eolivelli at gmail.com> wrote: > I confirm that with latest and greatest build of jdk11 Kafka index files > are no more "sparse" > Thank you very much ! > > b.q. I have troubles subscribing to this list, I am able to subscribe and > receive mails for other openjdk lists (jigsaw, code-libs..) but apparently > I can't subscribe to this list. Any idea ? > > > Enrico > > > Il giorno ven 4 mag 2018 alle ore 10:29 Alan Bateman < > Alan.Bateman at oracle.com> ha scritto: > >> On 27/04/2018 03:21, Ismael Juma wrote: >> > Sounds good, we can test the changes. >> > >> The changes for this issue are in jdk-11-ea+12 [1]. It would be great if >> you, or Enrico, could try Kafka with this build. >> >> -Alan >> >> [1] http://jdk.java.net/11/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180521/3d03a028/attachment.html> From yingqi.lu at intel.com Mon May 21 23:38:47 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Mon, 21 May 2018 23:38:47 +0000 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD140CEB6@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13A6B5F@ORSMSX113.amr.corp.intel.com> <c4844e84-2356-6fc1-9108-edcafe47e0bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD0D0@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> <78430e93-cd5f-13a5-363a-12f0c59e0405@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140CEB6@ORSMSX113.amr.corp.intel.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD140D909@ORSMSX113.amr.corp.intel.com> The JEP is updated with the feedback from Alan and Chris. https://bugs.openjdk.java.net/browse/JDK-8203434 Thanks, Lucy >-----Original Message----- >From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Lu, >Yingqi >Sent: Monday, May 21, 2018 8:51 AM >To: Alan Bateman <Alan.Bateman at oracle.com> >Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya ><sandhya.viswanathan at intel.com>; Aundhe, Shirish ><shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com> >Subject: RE: adding rsockets support into JDK > >Hi Alan, > >On the JEP, I will merge your feedback and Chris's feedback into the >document today. Since this is my first time drafting a JEP, what is the next step >I need to work on besides the webrev? > >On the patch, I will follow the example of DatagramChannelImpl >connect/accept for RDMA based channels and modify the code in the next >revision. > >Thank you! > >Lucy > >>-----Original Message----- >>From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>Sent: Monday, May 21, 2018 3:45 AM >>To: Lu, Yingqi <yingqi.lu at intel.com> >>Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya >><sandhya.viswanathan at intel.com>; Aundhe, Shirish >><shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com> >>Subject: Re: adding rsockets support into JDK >> >>On 18/05/2018 17:06, Lu, Yingqi wrote: >>> Thank you for your feedback, Alan! >>> >>> I will modify accordingly, update the JEP online and send a copy to >>> jdk-dev >>for broader review. >>> >>I read through the updated JEP (in JDK-8203434) and it reads well now. >> >>One suggestion is to split the Description so that the API is in its >>own section after the Description, and before Testing. That would give >>you a place to explain that the feature is platform specific / >>non-standard so the proposal is to add the API to the jdk.net module >>which is where JDK-specific networking features are exposed. The text >>you have after "Below is the list of proposed public APIs" can follow. >> >>One other thing is Risk/Assumption #2 where - >>Djava.net.preferIPv4Stack=true is needed. We updated the implementation >>in JDK 7 to allow for mixing of IPv4 and IPv6 sockets in the same VM >>and I think you should be able to make use of that and avoid needing to >>force all sockets be IPv4 sockets. The example to look at is >>DatagramChannelImpl as you can create a DatagramChannel to an IPv4-only >>socket. In the RDMA SocketChannel/ServerSocketChannel implementations >>then you should be able to specify the protocol family to >>connect/accept. You don't need to do this in a first version of course >>but I think addressing this point will make it a lot more usable. >> >>-Alan. From Alan.Bateman at oracle.com Tue May 22 06:39:22 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 May 2018 07:39:22 +0100 Subject: 8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space In-Reply-To: <CAD5tkZYYnAH=vaq2A_GWSVyjB1-WGM5yfWcg=4KuLNWGgR+gjg@mail.gmail.com> References: <e4a77f6f-841e-b36b-2c02-cae27b332550@oracle.com> <CAD5tkZYCn19dBwkcOfmv1GtAWVU9NewQV0SDW-8O15hUyZbDPg@mail.gmail.com> <CAD5tkZYTSgJry7PDQj5MYUzRMKDETFrPDh0z8ZFm3mHQinsbbw@mail.gmail.com> <68f27940-c00c-70e3-43ae-caba5fd7b821@oracle.com> <CAD5tkZa__byBGdBNR_HdUff3zoD61E5w-TkeN5g8pPRk4ON3rw@mail.gmail.com> <5c34a51a-d728-7671-bcbd-2b5e2766496b@oracle.com> <CACcefgfouwuhNepB4-XGGxoUJ=A1-pWWc-sdqQfZKEZLS+gJhw@mail.gmail.com> <CAD5tkZYYnAH=vaq2A_GWSVyjB1-WGM5yfWcg=4KuLNWGgR+gjg@mail.gmail.com> Message-ID: <d301ea74-6b83-e96f-8ac2-11a3428acaf5@oracle.com> On 21/05/2018 22:56, Ismael Juma wrote: > Any thoughts on a backport to Java 8? Java 10 would be nice to have, > but Java 11 is not far away and I don't expect many users to stick > with Java 10 for long given the update policy. However, many users > will stick to Java 8 for a long time and it would be good to restore > the behaviour there. > I don't have cycles to get involved in changes for JDK 8 updates. However, I agree JDK-8168628 should be backed out from jdk8u. -Alan From chris.hegarty at oracle.com Tue May 22 09:04:24 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 May 2018 10:04:24 +0100 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD140D909@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AD4CC@ORSMSX113.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> <78430e93-cd5f-13a5-363a-12f0c59e0405@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140CEB6@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140D909@ORSMSX113.amr.corp.intel.com> Message-ID: <220cf981-fdb6-9841-c6f6-4307a4d67fed@oracle.com> On 22/05/18 00:38, Lu, Yingqi wrote: > The JEP is updated with the feedback from Alan and Chris. > > https://bugs.openjdk.java.net/browse/JDK-8203434 From the latest draft: "On platforms where rsocket is not supported, UnsupportedOperationException is thrown on socket/*channel* operations." This does not sound right to me ( unless I am misinterpreting ). I read this to mean; on platforms without RDMA support, that openRdmaSocket() returns a Socket whose operations all throw UnsupportedOperationException. I would expect that openRdmaSocket() would throw UnsupportedOperationException, if RDMA is not supported. Similar with all the factory methods. Also, please consider capitalizing RDMA in factory method names. -Chris. From chris.hegarty at oracle.com Tue May 22 09:56:21 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 May 2018 10:56:21 +0100 Subject: adding rsockets support into JDK In-Reply-To: <220cf981-fdb6-9841-c6f6-4307a4d67fed@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> <78430e93-cd5f-13a5-363a-12f0c59e0405@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140CEB6@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140D909@ORSMSX113.amr.corp.intel.com> <220cf981-fdb6-9841-c6f6-4307a4d67fed@oracle.com> Message-ID: <c4e7b80d-ae5a-9a4c-6324-77e507a81d1f@oracle.com> Lucy, On 22/05/18 10:04, Chris Hegarty wrote: > ... > > Also, please consider capitalizing RDMA in factory method names. I withdraw this comment. Alan mentioned to me that the proposed names were already discussed. Please keep what you have. -Chris. From yingqi.lu at intel.com Tue May 22 16:26:38 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Tue, 22 May 2018 16:26:38 +0000 Subject: adding rsockets support into JDK In-Reply-To: <c4e7b80d-ae5a-9a4c-6324-77e507a81d1f@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <1c7d0657-3327-1349-d9e6-d12113c10aa4@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13AF403@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> <78430e93-cd5f-13a5-363a-12f0c59e0405@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140CEB6@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140D909@ORSMSX113.amr.corp.intel.com> <220cf981-fdb6-9841-c6f6-4307a4d67fed@oracle.com> <c4e7b80d-ae5a-9a4c-6324-77e507a81d1f@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD140E811@ORSMSX113.amr.corp.intel.com> Hi Chris, Thank you for reviewing the JEP. I already updated it based on your feedback. https://bugs.openjdk.java.net/browse/JDK-8203434 Thanks, Lucy >-----Original Message----- >From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >Sent: Tuesday, May 22, 2018 2:56 AM >To: Lu, Yingqi <yingqi.lu at intel.com> >Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya ><sandhya.viswanathan at intel.com>; Aundhe, Shirish ><shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com> >Subject: Re: adding rsockets support into JDK > >Lucy, > >On 22/05/18 10:04, Chris Hegarty wrote: >> ... >> >> Also, please consider capitalizing RDMA in factory method names. > >I withdraw this comment. Alan mentioned to me that the proposed names >were already discussed. Please keep what you have. > >-Chris. From chris.hegarty at oracle.com Tue May 22 17:03:55 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 May 2018 18:03:55 +0100 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD140E811@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> <78430e93-cd5f-13a5-363a-12f0c59e0405@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140CEB6@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140D909@ORSMSX113.amr.corp.intel.com> <220cf981-fdb6-9841-c6f6-4307a4d67fed@oracle.com> <c4e7b80d-ae5a-9a4c-6324-77e507a81d1f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140E811@ORSMSX113.amr.corp.intel.com> Message-ID: <b34266b1-175d-cc6f-5c16-622212f74e2e@oracle.com> Lucy, On 22/05/18 17:26, Lu, Yingqi wrote: > Hi Chris, > > Thank you for reviewing the JEP. I already updated it based on your feedback. > > https://bugs.openjdk.java.net/browse/JDK-8203434 Thank you for adding the clarification to when UnsupportedOperationException can be thrown. This draft JEP looks good to me. -Chris. From yingqi.lu at intel.com Tue May 22 17:18:55 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Tue, 22 May 2018 17:18:55 +0000 Subject: adding rsockets support into JDK In-Reply-To: <b34266b1-175d-cc6f-5c16-622212f74e2e@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> <78430e93-cd5f-13a5-363a-12f0c59e0405@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140CEB6@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140D909@ORSMSX113.amr.corp.intel.com> <220cf981-fdb6-9841-c6f6-4307a4d67fed@oracle.com> <c4e7b80d-ae5a-9a4c-6324-77e507a81d1f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140E811@ORSMSX113.amr.corp.intel.com> <b34266b1-175d-cc6f-5c16-622212f74e2e@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD140EAAA@ORSMSX113.amr.corp.intel.com> Hi Chris, Thank you for the help reviewing the JEP. Really appreciate! I am wondering what is the next step of the JEP? Is there anything else I need to do here or I just focus on the webrev instead? Thanks, Lucy >-----Original Message----- >From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >Sent: Tuesday, May 22, 2018 10:04 AM >To: Lu, Yingqi <yingqi.lu at intel.com> >Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya ><sandhya.viswanathan at intel.com>; Aundhe, Shirish ><shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com> >Subject: Re: adding rsockets support into JDK > >Lucy, > >On 22/05/18 17:26, Lu, Yingqi wrote: >> Hi Chris, >> >> Thank you for reviewing the JEP. I already updated it based on your >feedback. >> >> https://bugs.openjdk.java.net/browse/JDK-8203434 >Thank you for adding the clarification to when >UnsupportedOperationException can be thrown. > >This draft JEP looks good to me. > >-Chris. From chris.hegarty at oracle.com Wed May 23 08:10:56 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 23 May 2018 09:10:56 +0100 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD140EAAA@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> <78430e93-cd5f-13a5-363a-12f0c59e0405@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140CEB6@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140D909@ORSMSX113.amr.corp.intel.com> <220cf981-fdb6-9841-c6f6-4307a4d67fed@oracle.com> <c4e7b80d-ae5a-9a4c-6324-77e507a81d1f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140E811@ORSMSX113.amr.corp.intel.com> <b34266b1-175d-cc6f-5c16-622212f74e2e@oracle.com> <9! ACD5B67AAC5594CB6268234CF29CF9AD140EAAA@ORSMSX113.amr.corp.intel.com> Message-ID: <CF198B8C-D9C0-42DC-A5A8-F9CACE0D8289@oracle.com> > On 22 May 2018, at 18:18, Lu, Yingqi <yingqi.lu at intel.com> wrote: > > Hi Chris, > > Thank you for the help reviewing the JEP. Really appreciate! > > I am wondering what is the next step of the JEP? Since there has been some review on nio-dev and jdk-dev, then I suspect that you can move this JEP to ?Submitted?, as per the JEP process [1]. -Chris. [1] http://openjdk.java.net/jeps/1#Process-states From david.lloyd at redhat.com Wed May 23 13:04:40 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 23 May 2018 08:04:40 -0500 Subject: AF_LOCAL? (Was: Re: adding rsockets support into JDK) Message-ID: <CANghgrRydSNx=S1ytgCNUEiSEQmGYDTGYG+ade8eV8e1Z_A=RQ@mail.gmail.com> Given the precedent of RDMA sockets, what about introducing LocalSocketAddress/ProtocolFamily.AF_LOCAL (nee AF_UNIX) support, for those platforms which support it? Is this something that could, at this point, be realistically approved, were it proposed and implemented? On Tue, Jan 16, 2018 at 4:08 PM, Lu, Yingqi <yingqi.lu at intel.com> wrote: > Dear All, > > I have created a JBS to propose adding rsockets support into JDK so that all > Java based applications can take advantage of RDMA (Remote Direct Memory > Access). > > [...] -- - DML From david.lloyd at redhat.com Wed May 23 13:23:25 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 23 May 2018 08:23:25 -0500 Subject: AF_LOCAL? (Was: Re: adding rsockets support into JDK) In-Reply-To: <CANghgrRydSNx=S1ytgCNUEiSEQmGYDTGYG+ade8eV8e1Z_A=RQ@mail.gmail.com> References: <CANghgrRydSNx=S1ytgCNUEiSEQmGYDTGYG+ade8eV8e1Z_A=RQ@mail.gmail.com> Message-ID: <CANghgrSgKeS+oPwaPphXg1TmfiSTE3ytOemdXGNW3uL1xPjzJQ@mail.gmail.com> Related to this: https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-windows/ This means that we'd (eventually) be able to bring this to Windows as well. On Wed, May 23, 2018 at 8:04 AM, David Lloyd <david.lloyd at redhat.com> wrote: > Given the precedent of RDMA sockets, what about introducing > LocalSocketAddress/ProtocolFamily.AF_LOCAL (nee AF_UNIX) support, for > those platforms which support it? Is this something that could, at > this point, be realistically approved, were it proposed and > implemented? > > On Tue, Jan 16, 2018 at 4:08 PM, Lu, Yingqi <yingqi.lu at intel.com> wrote: >> Dear All, >> >> I have created a JBS to propose adding rsockets support into JDK so that all >> Java based applications can take advantage of RDMA (Remote Direct Memory >> Access). >> >> [...] > > -- > - DML -- - DML From david.lloyd at redhat.com Wed May 23 13:28:37 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 23 May 2018 08:28:37 -0500 Subject: [PATCH] 6350055: Atomic SelectionKey operations In-Reply-To: <fa4221ae-fafe-317d-f82f-855966795665@oracle.com> References: <CANghgrRgWCR2QnFoH=+tTDwaV1th7W+jHNntXy-QhaD4rZDAEQ@mail.gmail.com> <fa4221ae-fafe-317d-f82f-855966795665@oracle.com> Message-ID: <CANghgrRVpm5HAgV4V-z-uiGCYDz+Ru00fy2s+8U-r-qNZxAM-A@mail.gmail.com> The prophesied time has come. Here's the updated version [1], also attached. [1] https://github.com/dmlloyd/openjdk/tree/atomic-nio-ops-v7 On Tue, Apr 17, 2018 at 6:26 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > On 16/04/2018 23:34, David Lloyd wrote: >> >> On Fri, Mar 30, 2018 at 7:50 AM, Alan Bateman <Alan.Bateman at oracle.com> >> wrote: >>> >>> Once the queuing of updates is changed (to drop updateEvents) then this >>> will >>> be a lot simpler. >> >> Since some of the SelectionKey stuff has settled down a bit, I >> re-rebased this small patch. I've also located an old bug ID [1] >> which covers this functionality, though it would have to be reopened. >> Given our previous discussion I feel pretty confident that this can be >> done without too much controversy. >> >> The patch is attached and also available online here [2]. > > The spec looks okay except that it will need to be adjusted once we get the > changes for JDK-8201315 into jdk/jdk. If we get that in then the paragraph > on when interestOpsXXX can be called will change to: > > "This method may be invoked at any time. If this method is invoked while a > selection operation is in progress then it has no effect upon that > operation; the change to the key's interest set will be seen by the next > selection operation." > > -Alan -- - DML -------------- next part -------------- commit 39d09079a16a67a12d43cd8d09e6089d286b5b89 Author: David M. Lloyd <david.lloyd at redhat.com> Date: Wed Mar 28 13:13:44 2018 -0500 [JDK-6350055] Add atomic interest op methods to SelectionKey diff --git a/src/java.base/share/classes/java/nio/channels/SelectionKey.java b/src/java.base/share/classes/java/nio/channels/SelectionKey.java index ad08fe43822..cfc4faeae8e 100644 --- a/src/java.base/share/classes/java/nio/channels/SelectionKey.java +++ b/src/java.base/share/classes/java/nio/channels/SelectionKey.java @@ -189,6 +189,86 @@ public abstract class SelectionKey { */ public abstract SelectionKey interestOps(int ops); + /** + * Atomically sets this key's interest set to bitwise union ("or") of the existing + * interest set and the given value. This method is guaranteed to be + * atomic with respect to other concurrent calls to this method or to + * {@link #interestOpsAnd(int)}. + * + * <p> This method may be invoked at any time. If this method is invoked + * while a selection operation is in progress then it has no effect upon + * that operation; the change to the key's interest set will be seen by the + * next selection operation. + * + * @param ops The interest set to apply + * + * @return The previous interest set + * + * @throws IllegalArgumentException + * If a bit in the resultant set does not correspond to an operation that + * is supported by this key's channel, that is, if + * {@code ((interestOps() | ops) & ~channel().validOps()) != 0} + * + * @throws CancelledKeyException + * If this key has been cancelled + * + * @implSpec The default implementation synchronizes on this {@code SelectionKey} + * instance, calling {@link #interestOps()} and {@link #interestOps(int)} + * in turn; subclasses should provide a better implementation if + * possible (for example, using a + * {@link java.lang.invoke.VarHandle VarHandle} may be appropriate). + */ + public int interestOpsOr(int ops) { + synchronized (this) { + int oldVal = interestOps(); + interestOps(oldVal | ops); + return oldVal; + } + } + + /** + * Atomically sets this key's interest set to bitwise intersection ("and") of the + * existing interest set and the given value. This method is guaranteed to be + * atomic with respect to other concurrent calls to this method or to + * {@link #interestOpsOr(int)}. + * + * <p> This method may be invoked at any time. If this method is invoked + * while a selection operation is in progress then it has no effect upon + * that operation; the change to the key's interest set will be seen by the + * next selection operation. + * + * @param ops The interest set to apply + * + * @return The previous interest set + * + * @throws IllegalArgumentException + * If a bit in the resultant set does not correspond to an operation that + * is supported by this key's channel, that is, if + * {@code (interestOps() & ops & ~channel().validOps()) != 0} + * + * @throws CancelledKeyException + * If this key has been cancelled + * + * @apiNote The {@code ops} argument may contain bits which are not normally + * allowed by this key's channel, allowing bits to be cleared using + * bitwise complement values. For example, + * {@code interestOpsAnd(~SelectionKey.OP_READ)} will remove the + * {@code OP_READ} bit from the set without affecting other bits. + * + * @implSpec The default implementation synchronizes on this {@code SelectionKey} + * instance, calling {@link #interestOps()} and {@link #interestOps(int)} + * in turn; subclasses should provide a better implementation if + * possible (for example, using a + * {@link java.lang.invoke.VarHandle VarHandle} may be appropriate). + */ + public int interestOpsAnd(int ops) { + synchronized (this) { + int oldVal = interestOps(); + interestOps(oldVal & ops); + return oldVal; + } + } + /** * Retrieves this key's ready-operation set. * diff --git a/src/java.base/share/classes/sun/nio/ch/SelectionKeyImpl.java b/src/java.base/share/classes/sun/nio/ch/SelectionKeyImpl.java index 2f917c8d2e3..26b2afe2f08 100644 --- a/src/java.base/share/classes/sun/nio/ch/SelectionKeyImpl.java +++ b/src/java.base/share/classes/sun/nio/ch/SelectionKeyImpl.java @@ -25,6 +25,9 @@ package sun.nio.ch; +import java.lang.invoke.ConstantBootstraps; +import java.lang.invoke.MethodHandles; +import java.lang.invoke.VarHandle; import java.nio.channels.CancelledKeyException; import java.nio.channels.SelectableChannel; import java.nio.channels.SelectionKey; @@ -42,6 +45,10 @@ public final class SelectionKeyImpl private final SelChImpl channel; private final SelectorImpl selector; + private static final VarHandle interestOpsHandle = ConstantBootstraps.fieldVarHandle( + MethodHandles.lookup(), "interestOps", VarHandle.class, SelectionKeyImpl.class, int.class + ); + private volatile int interestOps; private volatile int readyOps; @@ -84,7 +91,35 @@ public final class SelectionKeyImpl @Override public SelectionKey interestOps(int ops) { ensureValid(); - return nioInterestOps(ops); + if ((ops & ~channel().validOps()) != 0) + throw new IllegalArgumentException(); + int oldOps = (int) interestOpsHandle.getAndSet(this, ops); + if (ops != oldOps) { + selector.setEventOps(this); + } + return this; + } + + @Override + public int interestOpsOr(final int ops) { + ensureValid(); + if ((ops & ~channel().validOps()) != 0) + throw new IllegalArgumentException(); + int oldVal = (int) interestOpsHandle.getAndBitwiseOr(this, ops); + if (oldVal != (oldVal | ops)) { + selector.setEventOps(this); + } + return oldVal; + } + + @Override + public int interestOpsAnd(final int ops) { + ensureValid(); + int oldVal = (int) interestOpsHandle.getAndBitwiseAnd(this, ops); + if (oldVal != (oldVal & ops)) { + selector.setEventOps(this); + } + return oldVal; } @Override From Alan.Bateman at oracle.com Wed May 23 13:57:44 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 May 2018 14:57:44 +0100 Subject: [PATCH] 6350055: Atomic SelectionKey operations In-Reply-To: <CANghgrRVpm5HAgV4V-z-uiGCYDz+Ru00fy2s+8U-r-qNZxAM-A@mail.gmail.com> References: <CANghgrRgWCR2QnFoH=+tTDwaV1th7W+jHNntXy-QhaD4rZDAEQ@mail.gmail.com> <fa4221ae-fafe-317d-f82f-855966795665@oracle.com> <CANghgrRVpm5HAgV4V-z-uiGCYDz+Ru00fy2s+8U-r-qNZxAM-A@mail.gmail.com> Message-ID: <d434891a-9c19-11f1-1192-32b5add61b8c@oracle.com> On 23/05/2018 14:28, David Lloyd wrote: > The prophesied time has come. Here's the updated version [1], also attached. > Do you have a test to include? If you add that then I think we can look at the cleanup issues and see what javadoc refs need to be added. -Alan From david.lloyd at redhat.com Wed May 23 14:00:16 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 23 May 2018 09:00:16 -0500 Subject: [PATCH] 6350055: Atomic SelectionKey operations In-Reply-To: <d434891a-9c19-11f1-1192-32b5add61b8c@oracle.com> References: <CANghgrRgWCR2QnFoH=+tTDwaV1th7W+jHNntXy-QhaD4rZDAEQ@mail.gmail.com> <fa4221ae-fafe-317d-f82f-855966795665@oracle.com> <CANghgrRVpm5HAgV4V-z-uiGCYDz+Ru00fy2s+8U-r-qNZxAM-A@mail.gmail.com> <d434891a-9c19-11f1-1192-32b5add61b8c@oracle.com> Message-ID: <CANghgrQDC-3CRCaiQ7_SxUwq9krMZOuaMHbpZm=F7pDAO7Fsxw@mail.gmail.com> I can probably add tests to show that the ops work. I'm not so sure that I can make a test that proves the atomicity of the operation though. On Wed, May 23, 2018 at 8:57 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > On 23/05/2018 14:28, David Lloyd wrote: >> >> The prophesied time has come. Here's the updated version [1], also >> attached. >> > Do you have a test to include? If you add that then I think we can look at > the cleanup issues and see what javadoc refs need to be added. > > -Alan -- - DML From yingqi.lu at intel.com Wed May 23 17:20:50 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Wed, 23 May 2018 17:20:50 +0000 Subject: adding rsockets support into JDK In-Reply-To: <CF198B8C-D9C0-42DC-A5A8-F9CACE0D8289@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13B4D12@ORSMSX113.amr.corp.intel.com> <440c90b4-ad38-568c-541c-9914d2139603@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD13CE4C7@ORSMSX113.amr.corp.intel.com> <16fc8dc7-5b55-264e-785c-5c76e0358d8f@oracle.com> <88B4FC61-EDCA-4017-8153-E002C4566E2F@intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1405409@ORSMSX113.amr.corp.intel.com> <8b9499e4-ce7c-544c-6e4a-9adc44aede5f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14095A4@ORSMSX113.amr.corp.intel.com> <78430e93-cd5f-13a5-363a-12f0c59e0405@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140CEB6@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140D909@ORSMSX113.amr.corp.intel.com> <220cf981-fdb6-9841-c6f6-4307a4d67fed@oracle.com> <c4e7b80d-ae5a-9a4c-6324-77e507a81d1f@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD140E811@ORSMSX113.amr.corp.intel.com> <b34266b1-175d-cc6f-5c16-622212f74e2e@oracle.com> <9! ACD5B67AAC5594CB6268234CF29CF9AD140EAAA@ORSMSX113.amr.corp.intel.com> <CF198B8C-D9C0-42DC-A5A8-F9CACE0D8289@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1410BC9@ORSMSX113.amr.corp.intel.com> Just move the status of the JEP from "draft" to "submitted". https://bugs.openjdk.java.net/browse/JDK-8203434 Thanks, Lucy >-----Original Message----- >From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >Sent: Wednesday, May 23, 2018 1:11 AM >To: Lu, Yingqi <yingqi.lu at intel.com> >Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya ><sandhya.viswanathan at intel.com>; Aundhe, Shirish ><shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com> >Subject: Re: adding rsockets support into JDK > > >> On 22 May 2018, at 18:18, Lu, Yingqi <yingqi.lu at intel.com> wrote: >> >> Hi Chris, >> >> Thank you for the help reviewing the JEP. Really appreciate! >> >> I am wondering what is the next step of the JEP? > >Since there has been some review on nio-dev and jdk-dev, then I suspect that >you can move this JEP to ?Submitted?, as per the JEP process [1]. > >-Chris. > >[1] http://openjdk.java.net/jeps/1#Process-states From brian.burkhalter at oracle.com Wed May 23 23:51:43 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 23 May 2018 16:51:43 -0700 Subject: 8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag Message-ID: <934E8230-8A21-4C59-AFD3-B7480ECCC906@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8203765 http://cr.openjdk.java.net/~bpb/8203765/webrev.00/ This test-only change modifies the information printed on failure and adds the @intermittent tag as the test fails occasionally albeit rarely. Thanks, Brian From Alan.Bateman at oracle.com Thu May 24 07:34:39 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 May 2018 08:34:39 +0100 Subject: 8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag In-Reply-To: <934E8230-8A21-4C59-AFD3-B7480ECCC906@oracle.com> References: <934E8230-8A21-4C59-AFD3-B7480ECCC906@oracle.com> Message-ID: <0702b6e5-cc4a-3dc8-74cf-f7edd3c716d3@oracle.com> On 24/05/2018 00:51, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8203765 > http://cr.openjdk.java.net/~bpb/8203765/webrev.00/ > > This test-only change modifies the information printed on failure and adds the @intermittent tag as the test fails occasionally albeit rarely. > I assume the issue with the test is that closeThread closes the Selector before selectThread calls select and this leads to the ClosedSelectorException. The test gives selectThread two seconds to block in select and it seems this is not enough on some (overloaded?) test systems. One suggestion is to "poll" the selectThread to see if it has locked the selector's selected key set with something like: while (!mayHoldLock(selectThread, selector.selectedKeys())) { ??? Thread.sleep(50); } where mayHoldLock gives some confidence that it is indeed locking the selected key set: ??? boolean mayHoldsLock(Thread t, Object lock) { ??????? long tid = t.getId(); ??????? int hash = System.identityHashCode(lock); ??????? ThreadInfo ti = ManagementFactory.getThreadMXBean().getThreadInfo(new long[]{ tid} , true, false, 100)[0]; ??????? if (ti != null) { ??????????? for (MonitorInfo mi : ti.getLockedMonitors()) { ??????????????? if (mi.getIdentityHashCode() == hash) ??????????????????? return true; ??????????? } ??????? } ??????? return false; ??? } If that works then you'll know that selectThread is in the select method and more importantly, it is past the check if the channel is closed. Another suggestion is to get rid of closeThread. I checked the original (JDK 1.4.x era) issue and it only needs two threads to create the conditions for the original bug. The main thread can be one of those. -Alan From brian.burkhalter at oracle.com Thu May 24 14:27:45 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 24 May 2018 07:27:45 -0700 Subject: 8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag In-Reply-To: <0702b6e5-cc4a-3dc8-74cf-f7edd3c716d3@oracle.com> References: <934E8230-8A21-4C59-AFD3-B7480ECCC906@oracle.com> <0702b6e5-cc4a-3dc8-74cf-f7edd3c716d3@oracle.com> Message-ID: <50663F6E-F9C7-4075-8A7A-ACDD5CF5A5B0@oracle.com> On May 24, 2018, at 12:34 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > I assume the issue with the test is that closeThread closes the Selector before selectThread calls select and this leads to the ClosedSelectorException. The test gives selectThread two seconds to block in select and it seems this is not enough on some (overloaded?) test systems. I did not see that there was a ClosedSelectorException thrown. > One suggestion is [?] Another suggestion is to get rid of closeThread. I was wondering whether it would be sufficient to put in the call selectThread.join() at the appropriate place. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180524/2efa2370/attachment.html> From brian.burkhalter at oracle.com Thu May 24 15:38:18 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 24 May 2018 08:38:18 -0700 Subject: 8203766: Add some instrumentation to jdk/java/nio/channels/Selector/RacyDeregister.java Message-ID: <3F86ABA6-987A-4F14-86AE-A8ABA76B0E4E@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8203766 http://cr.openjdk.java.net/~bpb/8203766/webrev.00/ This test-only change makes the test fail when it reaches 90% of the default timeout period if the test has not either passed or failed already. Hopefully if the test fails in this way there will be more information to corroborate the stack traces from the previously timed out execution. For example there might simply be too many iterations attempted on Windows. Thanks, Bria From Alan.Bateman at oracle.com Thu May 24 16:14:28 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 May 2018 17:14:28 +0100 Subject: 8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag In-Reply-To: <50663F6E-F9C7-4075-8A7A-ACDD5CF5A5B0@oracle.com> References: <934E8230-8A21-4C59-AFD3-B7480ECCC906@oracle.com> <0702b6e5-cc4a-3dc8-74cf-f7edd3c716d3@oracle.com> <50663F6E-F9C7-4075-8A7A-ACDD5CF5A5B0@oracle.com> Message-ID: <330d4889-a7bb-0294-bed5-f58c944adac9@oracle.com> On 24/05/2018 15:27, Brian Burkhalter wrote: > > On May 24, 2018, at 12:34 AM, Alan Bateman <Alan.Bateman at oracle.com > <mailto:Alan.Bateman at oracle.com>> wrote: > >> I assume the issue with the test is that closeThread closes the >> Selector before selectThread calls select and this leads to the >> ClosedSelectorException. The test gives selectThread two seconds to >> block in select and it seems this is not enough on some (overloaded?) >> test systems. > > I did not see that there was a?ClosedSelectorException thrown. > >> One suggestion is [?] Another suggestion is to get rid of closeThread. > > I was wondering whether it would be sufficient to put in the call > selectThread.join() at the appropriate place. > Waiting for the selectThread to terminate would at least allow you to capture the CloseSelectorException (assuming that is being thrown). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180524/1bab5d8a/attachment.html> From Alan.Bateman at oracle.com Thu May 24 16:16:38 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 May 2018 17:16:38 +0100 Subject: 8203766: Add some instrumentation to jdk/java/nio/channels/Selector/RacyDeregister.java In-Reply-To: <3F86ABA6-987A-4F14-86AE-A8ABA76B0E4E@oracle.com> References: <3F86ABA6-987A-4F14-86AE-A8ABA76B0E4E@oracle.com> Message-ID: <4902befa-a1db-13b8-99a2-63f525999929@oracle.com> On 24/05/2018 16:38, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8203766 > http://cr.openjdk.java.net/~bpb/8203766/webrev.00/ > > This test-only change makes the test fail when it reaches 90% of the default timeout period if the test has not either passed or failed already. Hopefully if the test fails in this way there will be more information to corroborate the stack traces from the previously timed out execution. For example there might simply be too many iterations attempted on Windows. > This looks okay and since you've added /timeout then it should give it more time on Windows (which I think is the only platform that will need the exact time). -Alan. From brian.burkhalter at oracle.com Thu May 24 16:29:04 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 24 May 2018 09:29:04 -0700 Subject: 8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag In-Reply-To: <330d4889-a7bb-0294-bed5-f58c944adac9@oracle.com> References: <934E8230-8A21-4C59-AFD3-B7480ECCC906@oracle.com> <0702b6e5-cc4a-3dc8-74cf-f7edd3c716d3@oracle.com> <50663F6E-F9C7-4075-8A7A-ACDD5CF5A5B0@oracle.com> <330d4889-a7bb-0294-bed5-f58c944adac9@oracle.com> Message-ID: <B807EF9A-88A0-4551-92F9-5A1920A8DAED@oracle.com> On May 24, 2018, at 9:14 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > Waiting for the selectThread to terminate would at least allow you to capture the CloseSelectorException (assuming that is being thrown). I did not see a CSE mentioned in the issue description / comments unless I missed something. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180524/b768a108/attachment-0001.html> From brian.burkhalter at oracle.com Thu May 24 17:30:18 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 24 May 2018 10:30:18 -0700 Subject: 8203766: Add some instrumentation to jdk/java/nio/channels/Selector/RacyDeregister.java In-Reply-To: <4902befa-a1db-13b8-99a2-63f525999929@oracle.com> References: <3F86ABA6-987A-4F14-86AE-A8ABA76B0E4E@oracle.com> <4902befa-a1db-13b8-99a2-63f525999929@oracle.com> Message-ID: <573E9870-A585-48FA-8C9F-6AE015BD03DF@oracle.com> On May 24, 2018, at 9:16 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > This looks okay and since you've added /timeout then it should give it more time on Windows (which I think is the only platform that will need the exact time). On Windows it was timing out in general after 1200 seconds which is the reason for this value. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180524/d13fb9db/attachment.html> From brian.burkhalter at oracle.com Thu May 24 19:41:01 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 24 May 2018 12:41:01 -0700 Subject: 8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag In-Reply-To: <B807EF9A-88A0-4551-92F9-5A1920A8DAED@oracle.com> References: <934E8230-8A21-4C59-AFD3-B7480ECCC906@oracle.com> <0702b6e5-cc4a-3dc8-74cf-f7edd3c716d3@oracle.com> <50663F6E-F9C7-4075-8A7A-ACDD5CF5A5B0@oracle.com> <330d4889-a7bb-0294-bed5-f58c944adac9@oracle.com> <B807EF9A-88A0-4551-92F9-5A1920A8DAED@oracle.com> Message-ID: <2D5F20B6-B2F4-493F-A518-410C432BF3D9@oracle.com> On May 24, 2018, at 9:29 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote: > On May 24, 2018, at 9:14 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > >> Waiting for the selectThread to terminate would at least allow you to capture the CloseSelectorException (assuming that is being thrown). > > I did not see a CSE mentioned in the issue description / comments unless I missed something. Updated version: http://cr.openjdk.java.net/~bpb/8203765/webrev.01/ Diff against version .00: --- a/test/jdk/java/nio/channels/Selector/SelectAndClose.java +++ b/test/jdk/java/nio/channels/Selector/SelectAndClose.java @@ -77,6 +77,9 @@ if (!awakened) selector.wakeup(); + // Wait for select() thread to finish. + selectThread.join(); + // Correct result is true and true if (!awakened || !closed) { System.err.format("selectThread is %s%n?, Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180524/f7185431/attachment.html> From ivan.gerasimov at oracle.com Thu May 24 20:57:56 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 24 May 2018 13:57:56 -0700 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes Message-ID: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> 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 are not required to be the same. For example, here's an extract from the Linux man page of send(): EAGAIN or EWOULDBLOCK The socket is marked nonblocking and the requested operation would block. POSIX.1-2001 allows either error to be returned for this case, and does not require these constants to have the same value, so a portable application should check for both possibilities. We should check for both error codes when appropriate. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8203369 WEBREV: http://cr.openjdk.java.net/~igerasim/8203369/00/webrev/ Thanks! -- With kind regards, Ivan Gerasimov From brian.burkhalter at oracle.com Fri May 25 00:30:19 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 24 May 2018 17:30:19 -0700 Subject: 8201407: Files.move throws DirectoryNonEmptyException when moving directory across file system In-Reply-To: <11d848fb-4a9e-8edd-c60f-8a19acd77e59@oracle.com> References: <F31E44D8-C2D0-43E0-8BB5-2A9D6044D7AE@oracle.com> <11d848fb-4a9e-8edd-c60f-8a19acd77e59@oracle.com> Message-ID: <42F4C5D8-248A-47ED-A29A-0A9330540216@oracle.com> On May 13, 2018, at 12:52 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: >> http://cr.openjdk.java.net/~bpb/8201407/webrev.00/ >> >> If this looks like the correct thing to do, then I will file a CSR, develop an analogous Windows fix, and add tests. >> > This subtly changes DirectoryNotEmptyException from an "optional specific exception" to a mandated exception. I think it would be better to just add to the existing @throws DirectoryNotEmptyException as the spec can't guarantee that you can throw this specific exception in all scenarios. > > As regards whether to attempt to check for entries before creating the target directory then that seems worth exploring. An updated version is at http://cr.openjdk.java.net/~bpb/8201407/webrev.01/. Note that the test will still fail for different reasons when -Dtest.dir specifies a different device. This is tracked by [1]. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8203803 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180524/58dac607/attachment.html> From david.holmes at oracle.com Fri May 25 02:44:13 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 May 2018 12:44:13 +1000 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes In-Reply-To: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> References: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> Message-ID: <1f8c5f31-d4d6-79d0-a24f-4d9ce66b59b1@oracle.com> Hi Ivan, Just a thought, but just because the actual native function may return either code, that doesn't mean our native wrapper can't treat them the same and present them to the Java code as one error? It seems pointless to double up these condition checks everywhere just in case there is some platform (do we know of one?) where this may be necessary. I also wonder whether a smart compiler might not flag code where the errors do infact have the same value: if (errno == 11 || errno == 11) ... Cheers, David On 25/05/2018 6:57 AM, 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 are not required to > be the same. > > For example, here's an extract from the Linux man page of send(): > EAGAIN or EWOULDBLOCK > The? socket? is marked nonblocking and the requested operation would > block.? POSIX.1-2001 allows either error to be returned for this case, > and does not require these constants to have the same value, so a > portable application should check for both possibilities. > > We should check for both error codes when appropriate. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8203369 > WEBREV: http://cr.openjdk.java.net/~igerasim/8203369/00/webrev/ > > Thanks! > From ivan.gerasimov at oracle.com Fri May 25 03:58:08 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 24 May 2018 20:58:08 -0700 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes In-Reply-To: <1f8c5f31-d4d6-79d0-a24f-4d9ce66b59b1@oracle.com> References: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> <1f8c5f31-d4d6-79d0-a24f-4d9ce66b59b1@oracle.com> Message-ID: <eae0ab4a-bc8d-16bb-83ce-2a6c28682ef6@oracle.com> Hi David! Thank you for reviewing the fix! On 5/24/18 7:44 PM, David Holmes wrote: > Hi Ivan, > > Just a thought, but just because the actual native function may return > either code, that doesn't mean our native wrapper can't treat them the > same and present them to the Java code as one error? > Currently in some places we check for only one of the values (on the supported platforms we could have being checking for the other with exactly same effect). In other places we already check for both values, so it is proposed to do it consistently with accordance to the documentation. > It seems pointless to double up these condition checks everywhere just > in case there is some platform (do we know of one?) where this may be > necessary. > That's exactly what man pages suggest: "...a portable application should check for both..." And yes, there exist such platforms. > I also wonder whether a smart compiler might not flag code where the > errors do infact have the same value: > > if (errno == 11 || errno == 11) ... > At least gcc -O completely removes the second redundant test, so no observable changes is expected on supported platforms. With kind regards, Ivan > Cheers, > David > > On 25/05/2018 6:57 AM, 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 are not required >> to be the same. >> >> For example, here's an extract from the Linux man page of send(): >> EAGAIN or EWOULDBLOCK >> The socket is marked nonblocking and the requested operation would >> block. POSIX.1-2001 allows either error to be returned for this >> case, and does not require these constants to have the same value, so >> a portable application should check for both possibilities. >> >> We should check for both error codes when appropriate. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8203369 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8203369/00/webrev/ >> >> Thanks! >> > -- With kind regards, Ivan Gerasimov From david.holmes at oracle.com Fri May 25 04:45:17 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 May 2018 14:45:17 +1000 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes In-Reply-To: <eae0ab4a-bc8d-16bb-83ce-2a6c28682ef6@oracle.com> References: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> <1f8c5f31-d4d6-79d0-a24f-4d9ce66b59b1@oracle.com> <eae0ab4a-bc8d-16bb-83ce-2a6c28682ef6@oracle.com> Message-ID: <3aac9d75-a24d-493b-d5a9-c255dcde9a4b@oracle.com> Hi Ivan, On 25/05/2018 1:58 PM, Ivan Gerasimov wrote: > Hi David! > > Thank you for reviewing the fix! I looked but did not review - it was just an observation :) > > On 5/24/18 7:44 PM, David Holmes wrote: >> Hi Ivan, >> >> Just a thought, but just because the actual native function may return >> either code, that doesn't mean our native wrapper can't treat them the >> same and present them to the Java code as one error? >> > Currently in some places we check for only one of the values (on the > supported platforms we could have being checking for the other with > exactly same effect).? In other places we already check for both values, > so it is proposed to do it consistently with accordance to the > documentation. > >> It seems pointless to double up these condition checks everywhere just >> in case there is some platform (do we know of one?) where this may be >> necessary. >> > That's exactly what man pages suggest: "...a portable application should > check for both..." Yes but that's the native code that calls the library methods. That doesn't necessarily mean we have to propagate the ambiguity through our own native wrappers and/or Java code. > And yes, there exist such platforms. > >> I also wonder whether a smart compiler might not flag code where the >> errors do infact have the same value: >> >> if (errno == 11 || errno == 11) ... >> > At least gcc -O completely removes the second redundant test, so no > observable changes is expected on supported platforms. I'm more worried about a new compiler warning - especially if you happened to use them in a switch! - resulting in future build failures. Cheers, David > With kind regards, > Ivan > >> Cheers, >> David >> >> On 25/05/2018 6:57 AM, 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 are not required >>> to be the same. >>> >>> For example, here's an extract from the Linux man page of send(): >>> EAGAIN or EWOULDBLOCK >>> The? socket? is marked nonblocking and the requested operation would >>> block.? POSIX.1-2001 allows either error to be returned for this >>> case, and does not require these constants to have the same value, so >>> a portable application should check for both possibilities. >>> >>> We should check for both error codes when appropriate. >>> >>> Would you please help review the fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8203369 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8203369/00/webrev/ >>> >>> Thanks! >>> >> > From weijun.wang at oracle.com Fri May 25 05:13:34 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 25 May 2018 13:13:34 +0800 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes In-Reply-To: <eae0ab4a-bc8d-16bb-83ce-2a6c28682ef6@oracle.com> References: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> <1f8c5f31-d4d6-79d0-a24f-4d9ce66b59b1@oracle.com> <eae0ab4a-bc8d-16bb-83ce-2a6c28682ef6@oracle.com> Message-ID: <DE20E9F8-FFC1-417C-B4CC-C0C609C4D7A9@oracle.com> > On May 25, 2018, at 11:58 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote: > >> I also wonder whether a smart compiler might not flag code where the errors do infact have the same value: >> >> if (errno == 11 || errno == 11) ... >> > At least gcc -O completely removes the second redundant test, so no observable changes is expected on supported platforms. And it silently compiles without showing any warning, right? Good if yes. --Max From weijun.wang at oracle.com Fri May 25 05:25:35 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 25 May 2018 13:25:35 +0800 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes In-Reply-To: <3aac9d75-a24d-493b-d5a9-c255dcde9a4b@oracle.com> References: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> <1f8c5f31-d4d6-79d0-a24f-4d9ce66b59b1@oracle.com> <eae0ab4a-bc8d-16bb-83ce-2a6c28682ef6@oracle.com> <3aac9d75-a24d-493b-d5a9-c255dcde9a4b@oracle.com> Message-ID: <713DA938-FE27-4604-A7FA-EE24B426F2D7@oracle.com> https://stackoverflow.com/questions/27509061/macro-to-avoid-duplicate-case-value Someone has already used them in a switch expression... > On May 25, 2018, at 12:45 PM, David Holmes <david.holmes at oracle.com> wrote: > >>> I also wonder whether a smart compiler might not flag code where the errors do infact have the same value: >>> >>> if (errno == 11 || errno == 11) ... >>> >> At least gcc -O completely removes the second redundant test, so no observable changes is expected on supported platforms. > > I'm more worried about a new compiler warning - especially if you happened to use them in a switch! - resulting in future build failures. From ivan.gerasimov at oracle.com Fri May 25 05:34:01 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 24 May 2018 22:34:01 -0700 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes In-Reply-To: <3aac9d75-a24d-493b-d5a9-c255dcde9a4b@oracle.com> References: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> <1f8c5f31-d4d6-79d0-a24f-4d9ce66b59b1@oracle.com> <eae0ab4a-bc8d-16bb-83ce-2a6c28682ef6@oracle.com> <3aac9d75-a24d-493b-d5a9-c255dcde9a4b@oracle.com> Message-ID: <78f664db-e9bb-d371-1a6e-21e8cf5e030e@oracle.com> Hi David! On 5/24/18 9:45 PM, David Holmes wrote: > > I looked but did not review - it was just an observation :) > Well, thank you anyway :) >> >>> It seems pointless to double up these condition checks everywhere >>> just in case there is some platform (do we know of one?) where this >>> may be necessary. >>> >> That's exactly what man pages suggest: "...a portable application >> should check for both..." > > Yes but that's the native code that calls the library methods. That > doesn't necessarily mean we have to propagate the ambiguity through > our own native wrappers and/or Java code. > Ah, I didn't immediately understood you're talking about constants in UnixConstants.java and LinuxWatchService.java. This part might probably be skipped (because we know that on Linux the constants have the same values), but I thought it's better it add it for consistency. In other parts of the fix we do treat the constants uniformly and propagate some non-ambiguous value to Java, like returning IOS_UNAVAILABLE in most cases. >> And yes, there exist such platforms. >> >>> I also wonder whether a smart compiler might not flag code where the >>> errors do infact have the same value: >>> >>> if (errno == 11 || errno == 11) ... >>> >> At least gcc -O completely removes the second redundant test, so no >> observable changes is expected on supported platforms. > > I'm more worried about a new compiler warning - especially if you > happened to use them in a switch! - resulting in future build failures. > What compiler do you mean: gcc or javac? If gcc, then we already have the same test for both constants in code with no issues. For example, java.base/unix/native/libnet/SocketInputStream.c, in NET_ReadWithTimeout(): result = NET_NonBlockingRead(fd, bufP, len); if (result == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) { If javac, then, I was thinking about it too, but I don't have a good a universal solution to propose right now. If one day someone needs to use these (platform dependent by definition) constants in switch, one will need to invent something to workaround the fact that some constants may have the same values on some platforms. With respect to EAGAIN and EWOULDBLOCK, it will be caught early enough because it will fail during the very first build on any currently supported Unix platform. With kind regards, Ivan > Cheers, > David > >> With kind regards, >> Ivan >> >>> Cheers, >>> David >>> >>> On 25/05/2018 6:57 AM, 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 are not >>>> required to be the same. >>>> >>>> For example, here's an extract from the Linux man page of send(): >>>> EAGAIN or EWOULDBLOCK >>>> The socket is marked nonblocking and the requested operation >>>> would block. POSIX.1-2001 allows either error to be returned for >>>> this case, and does not require these constants to have the same >>>> value, so a portable application should check for both possibilities. >>>> >>>> We should check for both error codes when appropriate. >>>> >>>> Would you please help review the fix? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8203369 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8203369/00/webrev/ >>>> >>>> Thanks! >>>> >>> >> > -- With kind regards, Ivan Gerasimov From david.holmes at oracle.com Fri May 25 05:43:10 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 May 2018 15:43:10 +1000 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes In-Reply-To: <78f664db-e9bb-d371-1a6e-21e8cf5e030e@oracle.com> References: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> <1f8c5f31-d4d6-79d0-a24f-4d9ce66b59b1@oracle.com> <eae0ab4a-bc8d-16bb-83ce-2a6c28682ef6@oracle.com> <3aac9d75-a24d-493b-d5a9-c255dcde9a4b@oracle.com> <78f664db-e9bb-d371-1a6e-21e8cf5e030e@oracle.com> Message-ID: <527790cd-b0bd-9d07-2036-22b02df5d80b@oracle.com> On 25/05/2018 3:34 PM, Ivan Gerasimov wrote: > Hi David! > > > On 5/24/18 9:45 PM, David Holmes wrote: >> >> I looked but did not review - it was just an observation :) >> > > Well, thank you anyway :) > >>> >>>> It seems pointless to double up these condition checks everywhere >>>> just in case there is some platform (do we know of one?) where this >>>> may be necessary. >>>> >>> That's exactly what man pages suggest: "...a portable application >>> should check for both..." >> >> Yes but that's the native code that calls the library methods. That >> doesn't necessarily mean we have to propagate the ambiguity through >> our own native wrappers and/or Java code. >> > Ah, I didn't immediately understood you're talking about constants in > UnixConstants.java and LinuxWatchService.java. > This part might probably be skipped (because we know that on Linux the > constants have the same values), but I thought it's better it add it for > consistency. > > In other parts of the fix we do treat the constants uniformly and > propagate some non-ambiguous value to Java, like returning > IOS_UNAVAILABLE in most cases. > >>> And yes, there exist such platforms. >>> >>>> I also wonder whether a smart compiler might not flag code where the >>>> errors do infact have the same value: >>>> >>>> if (errno == 11 || errno == 11) ... >>>> >>> At least gcc -O completely removes the second redundant test, so no >>> observable changes is expected on supported platforms. >> >> I'm more worried about a new compiler warning - especially if you >> happened to use them in a switch! - resulting in future build failures. >> > > What compiler do you mean: gcc or javac? gcc > If gcc, then we already have the same test for both constants in code > with no issues. > For example, java.base/unix/native/libnet/SocketInputStream.c, in > NET_ReadWithTimeout(): > ??????? result = NET_NonBlockingRead(fd, bufP, len); > ??????? if (result == -1 && ((errno == EAGAIN) || (errno == > EWOULDBLOCK))) { > > > If javac, then, I was thinking about it too, but I don't have a good a > universal solution to propose right now. javac should treat these symbolically rather than based on actual value, so I don't see any issue there. It's the C compiler that sees the raw value after preprocessing and so sees "duplicate" clauses. > If one day someone needs to use these (platform dependent by definition) > constants in switch, one will need to invent something to workaround the > fact that some constants may have the same values on some platforms. > With respect to EAGAIN and EWOULDBLOCK, it will be caught early enough > because it will fail during the very first build on any currently > supported Unix platform. Ok. Cheers, David > > With kind regards, > Ivan > > >> Cheers, >> David >> >>> With kind regards, >>> Ivan >>> >>>> Cheers, >>>> David >>>> >>>> On 25/05/2018 6:57 AM, 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 are not >>>>> required to be the same. >>>>> >>>>> For example, here's an extract from the Linux man page of send(): >>>>> EAGAIN or EWOULDBLOCK >>>>> The? socket? is marked nonblocking and the requested operation >>>>> would block.? POSIX.1-2001 allows either error to be returned for >>>>> this case, and does not require these constants to have the same >>>>> value, so a portable application should check for both possibilities. >>>>> >>>>> We should check for both error codes when appropriate. >>>>> >>>>> Would you please help review the fix? >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8203369 >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8203369/00/webrev/ >>>>> >>>>> Thanks! >>>>> >>>> >>> >> > From ivan.gerasimov at oracle.com Fri May 25 05:49:18 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 24 May 2018 22:49:18 -0700 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes In-Reply-To: <DE20E9F8-FFC1-417C-B4CC-C0C609C4D7A9@oracle.com> References: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> <1f8c5f31-d4d6-79d0-a24f-4d9ce66b59b1@oracle.com> <eae0ab4a-bc8d-16bb-83ce-2a6c28682ef6@oracle.com> <DE20E9F8-FFC1-417C-B4CC-C0C609C4D7A9@oracle.com> Message-ID: <c75fcc34-f022-dafa-f804-46eb3fda0206@oracle.com> Hi Wiijun! On 5/24/18 10:13 PM, Weijun Wang wrote: > >> On May 25, 2018, at 11:58 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote: >> >>> I also wonder whether a smart compiler might not flag code where the errors do infact have the same value: >>> >>> if (errno == 11 || errno == 11) ... >>> >> At least gcc -O completely removes the second redundant test, so no observable changes is expected on supported platforms. > And it silently compiles without showing any warning, right? Good if yes. > > --Max Yep, all is good. I've built/tested the patched JDK on all supported platforms with no issues. And we already have places, where both EAGAIN and EWOULDBLOCK are used in one if clause (as I just replied to David): java.base/unix/native/libnet/SocketInputStream.c, in NET_ReadWithTimeout(): result = NET_NonBlockingRead(fd, bufP, len); if (result == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) { So the fix basically proposes to use this approach consistently. With kind regards, Ivan -- With kind regards, Ivan Gerasimov From vyom.tewari at oracle.com Fri May 25 06:09:46 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Fri, 25 May 2018 11:39:46 +0530 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes In-Reply-To: <c75fcc34-f022-dafa-f804-46eb3fda0206@oracle.com> References: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> <1f8c5f31-d4d6-79d0-a24f-4d9ce66b59b1@oracle.com> <eae0ab4a-bc8d-16bb-83ce-2a6c28682ef6@oracle.com> <DE20E9F8-FFC1-417C-B4CC-C0C609C4D7A9@oracle.com> <c75fcc34-f022-dafa-f804-46eb3fda0206@oracle.com> Message-ID: <a5f08064-8bc4-61bc-1a0d-97683c1fecd6@oracle.com> On Friday 25 May 2018 11:19 AM, Ivan Gerasimov wrote: > Hi Wiijun! > > > On 5/24/18 10:13 PM, Weijun Wang wrote: >> >>> On May 25, 2018, at 11:58 AM, Ivan Gerasimov >>> <ivan.gerasimov at oracle.com> wrote: >>> >>>> I also wonder whether a smart compiler might not flag code where >>>> the errors do infact have the same value: >>>> >>>> if (errno == 11 || errno == 11) ... >>>> >>> At least gcc -O completely removes the second redundant test, so no >>> observable changes is expected on supported platforms. >> And it silently compiles without showing any warning, right? Good if >> yes. >> >> --Max > > Yep, all is good. > I've built/tested the patched JDK on all supported platforms with no > issues. > > And we already have places, where both EAGAIN and EWOULDBLOCK are used > in one if clause (as I just replied to David): > java.base/unix/native/libnet/SocketInputStream.c, in > NET_ReadWithTimeout(): > ??????? result = NET_NonBlockingRead(fd, bufP, len); > ??????? if (result == -1 && ((errno == EAGAIN) || (errno == > EWOULDBLOCK))) { > > i? wrote this code and that time even i wanted to fix the other native code (check error code for both EAGAIN & EWOULDBLOCK)? as you did ,but i did not . > So the fix basically proposes to use this approach consistently. we can at least fix the native part of code. Vyom > > > With kind regards, > Ivan > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180525/fa0814c2/attachment.html> From ivan.gerasimov at oracle.com Fri May 25 06:14:43 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 24 May 2018 23:14:43 -0700 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes In-Reply-To: <527790cd-b0bd-9d07-2036-22b02df5d80b@oracle.com> References: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> <1f8c5f31-d4d6-79d0-a24f-4d9ce66b59b1@oracle.com> <eae0ab4a-bc8d-16bb-83ce-2a6c28682ef6@oracle.com> <3aac9d75-a24d-493b-d5a9-c255dcde9a4b@oracle.com> <78f664db-e9bb-d371-1a6e-21e8cf5e030e@oracle.com> <527790cd-b0bd-9d07-2036-22b02df5d80b@oracle.com> Message-ID: <9b86e844-6a78-f0e3-d28c-e8d0c8f6b727@oracle.com> Hi David! >> If gcc, then we already have the same test for both constants in code >> with no issues. >> For example, java.base/unix/native/libnet/SocketInputStream.c, in >> NET_ReadWithTimeout(): >> result = NET_NonBlockingRead(fd, bufP, len); >> if (result == -1 && ((errno == EAGAIN) || (errno == >> EWOULDBLOCK))) { >> >> >> If javac, then, I was thinking about it too, but I don't have a good >> a universal solution to propose right now. > > javac should treat these symbolically rather than based on actual > value, so I don't see any issue there. It's the C compiler that sees > the raw value after preprocessing and so sees "duplicate" clauses. > If fact, as UnixContant.java is built from the template file UnixConstants.java.template, which is processed with cpp preprocessor, javac also sees the raw values. So if someone decides to write something like switch (exc.errno()) { case UnixConstants.EAGAIN: case UnixConstants.EWOULDBLOCK: } then there will be compile time trouble on some platforms and no issues on the others. Fortunately, UnixContant class is package private, so it is quite unlikely to happen. I was even thinking about proposing a language-level enhancement: If a switch statement contains duplicate cases *and* these are combined, then treat them as just one case. Though the use case it too limited to justify the need :) With kind regards, Ivan From ivan.gerasimov at oracle.com Fri May 25 06:34:37 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 24 May 2018 23:34:37 -0700 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes In-Reply-To: <713DA938-FE27-4604-A7FA-EE24B426F2D7@oracle.com> References: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> <1f8c5f31-d4d6-79d0-a24f-4d9ce66b59b1@oracle.com> <eae0ab4a-bc8d-16bb-83ce-2a6c28682ef6@oracle.com> <3aac9d75-a24d-493b-d5a9-c255dcde9a4b@oracle.com> <713DA938-FE27-4604-A7FA-EE24B426F2D7@oracle.com> Message-ID: <342b0e83-030f-4c98-3d59-c0f84e55adbd@oracle.com> On 5/24/18 10:25 PM, Weijun Wang wrote: > https://stackoverflow.com/questions/27509061/macro-to-avoid-duplicate-case-value > > Someone has already used them in a switch expression... Interesting! I like the very first solution: #if EAGAIN != EWOULDBLOCK case EAGAIN: #endif case EWOULDBLOCK: It is descriptive enough and compiles optimally. Fortunately, we don't have to care about it now, as the fix only adds checks of errno right after calls to system functions and does not store the errno value anywhere to analyze it later. -- With kind regards, Ivan Gerasimov From david.holmes at oracle.com Fri May 25 06:40:51 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 May 2018 16:40:51 +1000 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes In-Reply-To: <9b86e844-6a78-f0e3-d28c-e8d0c8f6b727@oracle.com> References: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> <1f8c5f31-d4d6-79d0-a24f-4d9ce66b59b1@oracle.com> <eae0ab4a-bc8d-16bb-83ce-2a6c28682ef6@oracle.com> <3aac9d75-a24d-493b-d5a9-c255dcde9a4b@oracle.com> <78f664db-e9bb-d371-1a6e-21e8cf5e030e@oracle.com> <527790cd-b0bd-9d07-2036-22b02df5d80b@oracle.com> <9b86e844-6a78-f0e3-d28c-e8d0c8f6b727@oracle.com> Message-ID: <ed5ca79f-f5ab-9b01-67c8-8bab70e1e2fc@oracle.com> On 25/05/2018 4:14 PM, Ivan Gerasimov wrote: > Hi David! > >>> If gcc, then we already have the same test for both constants in code >>> with no issues. >>> For example, java.base/unix/native/libnet/SocketInputStream.c, in >>> NET_ReadWithTimeout(): >>> ???????? result = NET_NonBlockingRead(fd, bufP, len); >>> ???????? if (result == -1 && ((errno == EAGAIN) || (errno == >>> EWOULDBLOCK))) { >>> >>> >>> If javac, then, I was thinking about it too, but I don't have a good >>> a universal solution to propose right now. >> >> javac should treat these symbolically rather than based on actual >> value, so I don't see any issue there. It's the C compiler that sees >> the raw value after preprocessing and so sees "duplicate" clauses. >> > If fact, as UnixContant.java is built from the template file > UnixConstants.java.template, which is processed with cpp preprocessor, > javac also sees the raw values. > > So if someone decides to write something like > switch (exc.errno()) { > ??? case UnixConstants.EAGAIN: > ??? case UnixConstants.EWOULDBLOCK: > } > then there will be compile time trouble on some platforms and no issues > on the others. I was thinking javac wouldn't examine the actual value of the fields, but it does for switch :( Oh well. David ----- > Fortunately, UnixContant class is package private, so it is quite > unlikely to happen. > > I was even thinking about proposing a language-level enhancement: If a > switch statement contains duplicate cases *and* these are combined, then > treat them as just one case. > Though the use case it too limited to justify the need :) > > With kind regards, > Ivan > > From Alan.Bateman at oracle.com Fri May 25 06:58:11 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2018 07:58:11 +0100 Subject: 8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag In-Reply-To: <2D5F20B6-B2F4-493F-A518-410C432BF3D9@oracle.com> References: <934E8230-8A21-4C59-AFD3-B7480ECCC906@oracle.com> <0702b6e5-cc4a-3dc8-74cf-f7edd3c716d3@oracle.com> <50663F6E-F9C7-4075-8A7A-ACDD5CF5A5B0@oracle.com> <330d4889-a7bb-0294-bed5-f58c944adac9@oracle.com> <B807EF9A-88A0-4551-92F9-5A1920A8DAED@oracle.com> <2D5F20B6-B2F4-493F-A518-410C432BF3D9@oracle.com> Message-ID: <782a2b23-9ddd-0730-38c3-ce77f4a4bdad@oracle.com> On 24/05/2018 20:41, Brian Burkhalter wrote: > > On May 24, 2018, at 9:29 AM, Brian Burkhalter > <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote: > >> On May 24, 2018, at 9:14 AM, Alan Bateman <Alan.Bateman at oracle.com >> <mailto:Alan.Bateman at oracle.com>> wrote: >> >>> Waiting for the selectThread to terminate would at least allow you >>> to capture the CloseSelectorException (assuming that is being thrown). >> >> I did not see a CSE mentioned in the issue description / comments >> unless I missed something. > > Updated version: http://cr.openjdk.java.net/~bpb/8203765/webrev.01/ > <http://cr.openjdk.java.net/%7Ebpb/8203765/webrev.01/> > My preference would be to re-work the test so that main thread waits until selectThread is in select. That eliminates the sleep(2000) and avoids the potential ClosedSelectorException that happens when closeThread closes the selector before selectThread blocks in select. The changes you have are benign of course but think we should just fix the test now rather than having to look at it again in 6 months when it fails again. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180525/724611c3/attachment-0001.html> From Alan.Bateman at oracle.com Fri May 25 11:27:47 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2018 12:27:47 +0100 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes In-Reply-To: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> References: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> Message-ID: <d49b1b70-8fdb-1f0c-57ec-b273a4d2fd55@oracle.com> 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 are not required > to be the same. > > For example, here's an extract from the Linux man page of send(): > EAGAIN or EWOULDBLOCK > The? socket? is marked nonblocking and the requested operation would > block.? POSIX.1-2001 allows either error to be returned for this case, > and does not require these constants to have the same value, so a > portable application should check for both possibilities. > > We should check for both error codes when appropriate. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8203369 > WEBREV: http://cr.openjdk.java.net/~igerasim/8203369/00/webrev/ The changes in 01/webrev look okay to me but I'm curious if there are any ports in OpenJDK where the values are different. If they are different then I would assume that many tests will fail. -Alan From Alan.Bateman at oracle.com Fri May 25 13:03:31 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2018 14:03:31 +0100 Subject: 8201407: Files.move throws DirectoryNonEmptyException when moving directory across file system In-Reply-To: <42F4C5D8-248A-47ED-A29A-0A9330540216@oracle.com> References: <F31E44D8-C2D0-43E0-8BB5-2A9D6044D7AE@oracle.com> <11d848fb-4a9e-8edd-c60f-8a19acd77e59@oracle.com> <42F4C5D8-248A-47ED-A29A-0A9330540216@oracle.com> Message-ID: <d1c42626-9da0-c389-0534-e8ad12e41851@oracle.com> On 25/05/2018 01:30, Brian Burkhalter wrote: > > An updated version is at > http://cr.openjdk.java.net/~bpb/8201407/webrev.01/ > <http://cr.openjdk.java.net/%7Ebpb/8201407/webrev.01/>. > > Note that the test will still fail for different reasons when > -Dtest.dir specifies a different device. This is tracked by [1]. > This version looks a lot better. I think the spec update is okay. The implementation changes would be cleaner if we add an isEmptyDir method. Also in the Windows implementation would be easier to read if you specify the filter as `e -> true`. I wasn't aware that setting -Dtest.dir to a different file system breaks this test. This was an important testing mode when this test was originally created. -Alan. From chris.hegarty at oracle.com Fri May 25 13:15:01 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 25 May 2018 14:15:01 +0100 Subject: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes In-Reply-To: <d49b1b70-8fdb-1f0c-57ec-b273a4d2fd55@oracle.com> References: <a889c361-b096-6648-851d-3dc7f03ce691@oracle.com> <d49b1b70-8fdb-1f0c-57ec-b273a4d2fd55@oracle.com> Message-ID: <79ddfc04-e017-4c59-b7fb-976763647855@oracle.com> Alan, On 25/05/18 12:27, Alan Bateman wrote: > On 24/05/2018 21:57, Ivan Gerasimov wrote: >> .. >> WEBREV: http://cr.openjdk.java.net/~igerasim/8203369/00/webrev/ > The changes in 01/webrev look okay to me but I'm curious if there are > any ports in OpenJDK where the values are different. HPUX 11.31 ( on Itanium IA-64 ) does indeed have EAGAIN and EWOULDBLOCK defined to be different values. This is the main motivation for resolving this issue. /usr/include/sys/errno.h:#define EAGAIN 11 /* No more processes */ /usr/include/sys/errno.h:#define EWOULDBLOCK 246 /* Operation would block */ > If they are different then I would assume that many tests will fail. Yes. -Chris. From brian.burkhalter at oracle.com Fri May 25 14:03:56 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 25 May 2018 07:03:56 -0700 Subject: 8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag In-Reply-To: <782a2b23-9ddd-0730-38c3-ce77f4a4bdad@oracle.com> References: <934E8230-8A21-4C59-AFD3-B7480ECCC906@oracle.com> <0702b6e5-cc4a-3dc8-74cf-f7edd3c716d3@oracle.com> <50663F6E-F9C7-4075-8A7A-ACDD5CF5A5B0@oracle.com> <330d4889-a7bb-0294-bed5-f58c944adac9@oracle.com> <B807EF9A-88A0-4551-92F9-5A1920A8DAED@oracle.com> <2D5F20B6-B2F4-493F-A518-410C432BF3D9@oracle.com> <782a2b23-9ddd-0730-38c3-ce77f4a4bdad@oracle.com> Message-ID: <6A37AD7E-1EE0-49D5-8A87-506B081A7164@oracle.com> On May 24, 2018, at 11:58 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > My preference would be to re-work the test so that main thread waits until selectThread is in select. That eliminates the sleep(2000) and avoids the potential ClosedSelectorException that happens when closeThread closes the selector before selectThread blocks in select. The changes you have are benign of course but think we should just fix the test now rather than having to look at it again in 6 months when it fails again. All right, I will take another look at it next week. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180525/bde33bc6/attachment.html> From brian.burkhalter at oracle.com Fri May 25 14:05:43 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 25 May 2018 07:05:43 -0700 Subject: 8201407: Files.move throws DirectoryNonEmptyException when moving directory across file system In-Reply-To: <d1c42626-9da0-c389-0534-e8ad12e41851@oracle.com> References: <F31E44D8-C2D0-43E0-8BB5-2A9D6044D7AE@oracle.com> <11d848fb-4a9e-8edd-c60f-8a19acd77e59@oracle.com> <42F4C5D8-248A-47ED-A29A-0A9330540216@oracle.com> <d1c42626-9da0-c389-0534-e8ad12e41851@oracle.com> Message-ID: <ADD39970-D6C2-43C8-B614-B7AF339286B4@oracle.com> On May 25, 2018, at 6:03 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > This version looks a lot better. I think the spec update is okay. > > The implementation changes would be cleaner if we add an isEmptyDir method. Also in the Windows implementation would be easier to read if you specify the filter as `e -> true`. I will look at the foregoing next week. > I wasn't aware that setting -Dtest.dir to a different file system breaks this test. This was an important testing mode when this test was originally created. I don?t imagine that -Dtest.dir is a scenario typically run in CI builds. Something needs to be figured out here to make it get executed at least occasionally by default. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180525/dfd2b2d4/attachment.html> From brian.burkhalter at oracle.com Tue May 29 23:21:10 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 29 May 2018 16:21:10 -0700 Subject: 8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag In-Reply-To: <6A37AD7E-1EE0-49D5-8A87-506B081A7164@oracle.com> References: <934E8230-8A21-4C59-AFD3-B7480ECCC906@oracle.com> <0702b6e5-cc4a-3dc8-74cf-f7edd3c716d3@oracle.com> <50663F6E-F9C7-4075-8A7A-ACDD5CF5A5B0@oracle.com> <330d4889-a7bb-0294-bed5-f58c944adac9@oracle.com> <B807EF9A-88A0-4551-92F9-5A1920A8DAED@oracle.com> <2D5F20B6-B2F4-493F-A518-410C432BF3D9@oracle.com> <782a2b23-9ddd-0730-38c3-ce77f4a4bdad@oracle.com> <6A37AD7E-1EE0-49D5-8A87-506B081A7164@oracle.com> Message-ID: <EBCF595C-E6D9-4FF3-A9FC-13651E5DD5C5@oracle.com> On May 25, 2018, at 7:03 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote: > On May 24, 2018, at 11:58 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > >> My preference would be to re-work the test so that main thread waits until selectThread is in select. That eliminates the sleep(2000) and avoids the potential ClosedSelectorException that happens when closeThread closes the selector before selectThread blocks in select. The changes you have are benign of course but think we should just fix the test now rather than having to look at it again in 6 months when it fails again. > > All right, I will take another look at it next week. After studying your previous suggestion [1] in detail, I agree that it is better. I have implemented it in the updated patch [2] which has been run through build-and-test on Linux and Windows with 100 test repeats sans failure. Thanks, Brian [1] http://mail.openjdk.java.net/pipermail/nio-dev/2018-May/005146.html [2] http://cr.openjdk.java.net/~bpb/8203765/webrev.02/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180529/75d03ccd/attachment.html> From Alan.Bateman at oracle.com Wed May 30 07:19:29 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 May 2018 08:19:29 +0100 Subject: 8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag In-Reply-To: <EBCF595C-E6D9-4FF3-A9FC-13651E5DD5C5@oracle.com> References: <934E8230-8A21-4C59-AFD3-B7480ECCC906@oracle.com> <0702b6e5-cc4a-3dc8-74cf-f7edd3c716d3@oracle.com> <50663F6E-F9C7-4075-8A7A-ACDD5CF5A5B0@oracle.com> <330d4889-a7bb-0294-bed5-f58c944adac9@oracle.com> <B807EF9A-88A0-4551-92F9-5A1920A8DAED@oracle.com> <2D5F20B6-B2F4-493F-A518-410C432BF3D9@oracle.com> <782a2b23-9ddd-0730-38c3-ce77f4a4bdad@oracle.com> <6A37AD7E-1EE0-49D5-8A87-506B081A7164@oracle.com> <EBCF595C-E6D9-4FF3-A9FC-13651E5DD5C5@oracle.com> Message-ID: <0c2c3fa6-66de-18ac-440b-35c68c0336c1@oracle.com> On 30/05/2018 00:21, Brian Burkhalter wrote: > > After studying your previous suggestion [1] in detail, I agree that it > is better. I have implemented it in the updated patch [2] which has > been run through build-and-test on Linux and Windows with 100 test > repeats sans failure. > Good, I think this is the right approach as it re-works the test now as the issues are clear. A few comments: - no need to add the intermittent tag, that may be left over from your original patch - most of the comment on mightHoldKeySetLock can be replaced with a comment to say that selection operations are specified to synchronize on the selected key set. Also there is nothing in this method that knows anything about selector or the selected-key set so it could be renamed (to drop "KeySet") and the comment can be moved to the while loop in main where it calls the method with the selected-key set. - no need for the try/catch around selector.close, it's okay to have the main method throw IOException -Alan From brian.burkhalter at oracle.com Wed May 30 14:25:09 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 30 May 2018 07:25:09 -0700 Subject: 8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag In-Reply-To: <0c2c3fa6-66de-18ac-440b-35c68c0336c1@oracle.com> References: <934E8230-8A21-4C59-AFD3-B7480ECCC906@oracle.com> <0702b6e5-cc4a-3dc8-74cf-f7edd3c716d3@oracle.com> <50663F6E-F9C7-4075-8A7A-ACDD5CF5A5B0@oracle.com> <330d4889-a7bb-0294-bed5-f58c944adac9@oracle.com> <B807EF9A-88A0-4551-92F9-5A1920A8DAED@oracle.com> <2D5F20B6-B2F4-493F-A518-410C432BF3D9@oracle.com> <782a2b23-9ddd-0730-38c3-ce77f4a4bdad@oracle.com> <6A37AD7E-1EE0-49D5-8A87-506B081A7164@oracle.com> <EBCF595C-E6D9-4FF3-A9FC-13651E5DD5C5@oracle.com> <0c2c3fa6-66de-18ac-440b-35c68c0336c1@oracle.com> Message-ID: <413ACCD0-D8F5-49CD-B614-779C96A8E44B@oracle.com> On May 30, 2018, at 12:19 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > Good, I think this is the right approach as it re-works the test now as the issues are clear. A few comments: It was an excellent idea - thanks. > - no need to add the intermittent tag, that may be left over from your original patch Shall excise. > - most of the comment on mightHoldKeySetLock can be replaced with a comment to say that selection operations are specified to synchronize on the selected key set. I realize it?s overkill. I was clarifying it for myself. > Also there is nothing in this method that knows anything about selector or the selected-key set so it could be renamed (to drop "KeySet") and the comment can be moved to the while loop in main where it calls the method with the selected-key set. Yes, I thought of that. > - no need for the try/catch around selector.close, it's okay to have the main method throw IOException Will change before the push. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180530/9fac9bea/attachment.html> From david.lloyd at redhat.com Wed May 30 18:14:36 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 30 May 2018 13:14:36 -0500 Subject: [PATCH] 6350055: Atomic SelectionKey operations In-Reply-To: <CANghgrQDC-3CRCaiQ7_SxUwq9krMZOuaMHbpZm=F7pDAO7Fsxw@mail.gmail.com> References: <CANghgrRgWCR2QnFoH=+tTDwaV1th7W+jHNntXy-QhaD4rZDAEQ@mail.gmail.com> <fa4221ae-fafe-317d-f82f-855966795665@oracle.com> <CANghgrRVpm5HAgV4V-z-uiGCYDz+Ru00fy2s+8U-r-qNZxAM-A@mail.gmail.com> <d434891a-9c19-11f1-1192-32b5add61b8c@oracle.com> <CANghgrQDC-3CRCaiQ7_SxUwq9krMZOuaMHbpZm=F7pDAO7Fsxw@mail.gmail.com> Message-ID: <CANghgrSg01jccDXDFU8U=io5nP7gL6DUsBbfedjFY1T8x1Wavw@mail.gmail.com> On Wed, May 23, 2018 at 9:00 AM, David Lloyd <david.lloyd at redhat.com> wrote: > I can probably add tests to show that the ops work. I'm not so sure > that I can make a test that proves the atomicity of the operation > though. Updated with tests [1] & attached. [1] https://github.com/dmlloyd/openjdk/commit/atomic-nio-ops-v8 -- - DML -------------- next part -------------- commit 9cb94bfcef0a25ba6a5f8e79462f01a7df08ac09 Author: David M. Lloyd <david.lloyd at redhat.com> Date: Wed Mar 28 13:13:44 2018 -0500 [JDK-6350055] Add atomic interest op methods to SelectionKey diff --git a/src/java.base/share/classes/java/nio/channels/SelectionKey.java b/src/java.base/share/classes/java/nio/channels/SelectionKey.java index ad08fe43822..cfc4faeae8e 100644 --- a/src/java.base/share/classes/java/nio/channels/SelectionKey.java +++ b/src/java.base/share/classes/java/nio/channels/SelectionKey.java @@ -189,6 +189,86 @@ public abstract class SelectionKey { */ public abstract SelectionKey interestOps(int ops); + /** + * Atomically sets this key's interest set to bitwise union ("or") of the existing + * interest set and the given value. This method is guaranteed to be + * atomic with respect to other concurrent calls to this method or to + * {@link #interestOpsAnd(int)}. + * + * <p> This method may be invoked at any time. If this method is invoked + * while a selection operation is in progress then it has no effect upon + * that operation; the change to the key's interest set will be seen by the + * next selection operation. + * + * @param ops The interest set to apply + * + * @return The previous interest set + * + * @throws IllegalArgumentException + * If a bit in the resultant set does not correspond to an operation that + * is supported by this key's channel, that is, if + * {@code ((interestOps() | ops) & ~channel().validOps()) != 0} + * + * @throws CancelledKeyException + * If this key has been cancelled + * + * @implSpec The default implementation synchronizes on this {@code SelectionKey} + * instance, calling {@link #interestOps()} and {@link #interestOps(int)} + * in turn; subclasses should provide a better implementation if + * possible (for example, using a + * {@link java.lang.invoke.VarHandle VarHandle} may be appropriate). + */ + public int interestOpsOr(int ops) { + synchronized (this) { + int oldVal = interestOps(); + interestOps(oldVal | ops); + return oldVal; + } + } + + /** + * Atomically sets this key's interest set to bitwise intersection ("and") of the + * existing interest set and the given value. This method is guaranteed to be + * atomic with respect to other concurrent calls to this method or to + * {@link #interestOpsOr(int)}. + * + * <p> This method may be invoked at any time. If this method is invoked + * while a selection operation is in progress then it has no effect upon + * that operation; the change to the key's interest set will be seen by the + * next selection operation. + * + * @param ops The interest set to apply + * + * @return The previous interest set + * + * @throws IllegalArgumentException + * If a bit in the resultant set does not correspond to an operation that + * is supported by this key's channel, that is, if + * {@code (interestOps() & ops & ~channel().validOps()) != 0} + * + * @throws CancelledKeyException + * If this key has been cancelled + * + * @apiNote The {@code ops} argument may contain bits which are not normally + * allowed by this key's channel, allowing bits to be cleared using + * bitwise complement values. For example, + * {@code interestOpsAnd(~SelectionKey.OP_READ)} will remove the + * {@code OP_READ} bit from the set without affecting other bits. + * + * @implSpec The default implementation synchronizes on this {@code SelectionKey} + * instance, calling {@link #interestOps()} and {@link #interestOps(int)} + * in turn; subclasses should provide a better implementation if + * possible (for example, using a + * {@link java.lang.invoke.VarHandle VarHandle} may be appropriate). + */ + public int interestOpsAnd(int ops) { + synchronized (this) { + int oldVal = interestOps(); + interestOps(oldVal & ops); + return oldVal; + } + } + /** * Retrieves this key's ready-operation set. * diff --git a/src/java.base/share/classes/sun/nio/ch/SelectionKeyImpl.java b/src/java.base/share/classes/sun/nio/ch/SelectionKeyImpl.java index 2f917c8d2e3..26b2afe2f08 100644 --- a/src/java.base/share/classes/sun/nio/ch/SelectionKeyImpl.java +++ b/src/java.base/share/classes/sun/nio/ch/SelectionKeyImpl.java @@ -25,6 +25,9 @@ package sun.nio.ch; +import java.lang.invoke.ConstantBootstraps; +import java.lang.invoke.MethodHandles; +import java.lang.invoke.VarHandle; import java.nio.channels.CancelledKeyException; import java.nio.channels.SelectableChannel; import java.nio.channels.SelectionKey; @@ -42,6 +45,10 @@ public final class SelectionKeyImpl private final SelChImpl channel; private final SelectorImpl selector; + private static final VarHandle interestOpsHandle = ConstantBootstraps.fieldVarHandle( + MethodHandles.lookup(), "interestOps", VarHandle.class, SelectionKeyImpl.class, int.class + ); + private volatile int interestOps; private volatile int readyOps; @@ -84,7 +91,35 @@ public final class SelectionKeyImpl @Override public SelectionKey interestOps(int ops) { ensureValid(); - return nioInterestOps(ops); + if ((ops & ~channel().validOps()) != 0) + throw new IllegalArgumentException(); + int oldOps = (int) interestOpsHandle.getAndSet(this, ops); + if (ops != oldOps) { + selector.setEventOps(this); + } + return this; + } + + @Override + public int interestOpsOr(final int ops) { + ensureValid(); + if ((ops & ~channel().validOps()) != 0) + throw new IllegalArgumentException(); + int oldVal = (int) interestOpsHandle.getAndBitwiseOr(this, ops); + if (oldVal != (oldVal | ops)) { + selector.setEventOps(this); + } + return oldVal; + } + + @Override + public int interestOpsAnd(final int ops) { + ensureValid(); + int oldVal = (int) interestOpsHandle.getAndBitwiseAnd(this, ops); + if (oldVal != (oldVal & ops)) { + selector.setEventOps(this); + } + return oldVal; } @Override diff --git a/test/jdk/java/nio/channels/Selector/AtomicSelectionKeyOps.java b/test/jdk/java/nio/channels/Selector/AtomicSelectionKeyOps.java new file mode 100644 index 00000000000..ac647741fa9 --- /dev/null +++ b/test/jdk/java/nio/channels/Selector/AtomicSelectionKeyOps.java @@ -0,0 +1,149 @@ +/* + * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Oracle designates this + * particular file as subject to the "Classpath" exception as provided + * by Oracle in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* @test + * @run testng ValidateSelectionKeyOps + * @summary Test that the operations on SelectionKey function as specified. + */ + +import java.io.Closeable; +import java.io.IOException; +import java.net.InetAddress; +import java.net.InetSocketAddress; +import java.nio.channels.SelectableChannel; +import java.nio.channels.SelectionKey; +import java.nio.channels.Selector; +import java.nio.channels.ServerSocketChannel; +import java.nio.channels.SocketChannel; +import org.testng.annotations.Test; + +import static java.nio.channels.SelectionKey.OP_READ; +import static java.nio.channels.SelectionKey.OP_WRITE; +import static java.nio.channels.SelectionKey.OP_CONNECT; +import static java.nio.channels.SelectionKey.OP_ACCEPT; +import static org.testng.Assert.*; + + at Test +public class AtomicSelectionKeyOps { + + public void testBaseImplementation() throws Exception { + SelectionKey testKeyImpl = new SelectionKey() { + private int ops; + + public SelectableChannel channel() { + return null; + } + + public Selector selector() { + return null; + } + + public boolean isValid() { + return true; + } + + public void cancel() { + } + + public int interestOps() { + return ops; + } + + public SelectionKey interestOps(final int ops) { + this.ops = ops; + return this; + } + + public int readyOps() { + return 0; + } + }; + + assertEquals(testKeyImpl.interestOps(), 0); + testKeyImpl.interestOps(OP_READ); + assertEquals(testKeyImpl.interestOps(), OP_READ); + testKeyImpl.interestOpsOr(OP_ACCEPT | OP_WRITE); + assertEquals(testKeyImpl.interestOps(), OP_READ | OP_WRITE | OP_ACCEPT); + testKeyImpl.interestOpsAnd(OP_WRITE | OP_CONNECT); + assertEquals(testKeyImpl.interestOps(), OP_WRITE); + testKeyImpl.interestOpsOr(OP_CONNECT); + assertEquals(testKeyImpl.interestOps(), OP_WRITE | OP_CONNECT); + testKeyImpl.interestOpsAnd(OP_READ); + assertEquals(testKeyImpl.interestOps(), 0); + } + + public void testNioImplementation() throws Exception { + final Selector selector = Selector.open(); + final ConnectionPair pair = new ConnectionPair(); + final SocketChannel channel = pair.channel1(); + channel.configureBlocking(false); + final SelectionKey selectionKey = channel.register(selector, 0); + assertEquals(selectionKey.interestOps(), 0); + selectionKey.interestOps(OP_READ); + assertEquals(selectionKey.interestOps(), OP_READ); + try { + selectionKey.interestOpsOr(OP_ACCEPT | OP_WRITE); + fail("Expected exception"); + } catch (IllegalArgumentException okay) {} + selectionKey.interestOpsOr(OP_WRITE); + assertEquals(selectionKey.interestOps(), OP_READ | OP_WRITE); + selectionKey.interestOpsAnd(OP_WRITE | OP_CONNECT); + assertEquals(selectionKey.interestOps(), OP_WRITE); + selectionKey.interestOpsOr(OP_CONNECT); + assertEquals(selectionKey.interestOps(), OP_WRITE | OP_CONNECT); + selectionKey.interestOpsAnd(OP_READ); + assertEquals(selectionKey.interestOps(), 0); + pair.close(); + } + + static class ConnectionPair implements Closeable { + + private final SocketChannel sc1; + private final SocketChannel sc2; + + ConnectionPair() throws IOException { + InetAddress lb = InetAddress.getLoopbackAddress(); + try (ServerSocketChannel ssc = ServerSocketChannel.open()) { + ssc.bind(new InetSocketAddress(lb, 0)); + this.sc1 = SocketChannel.open(ssc.getLocalAddress()); + this.sc2 = ssc.accept(); + } + } + + SocketChannel channel1() { + return sc1; + } + + SocketChannel channel2() { + return sc2; + } + + public void close() throws IOException { + sc1.close(); + sc2.close(); + } + } +} + From brian.burkhalter at oracle.com Wed May 30 20:56:53 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 30 May 2018 13:56:53 -0700 Subject: 8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag In-Reply-To: <413ACCD0-D8F5-49CD-B614-779C96A8E44B@oracle.com> References: <934E8230-8A21-4C59-AFD3-B7480ECCC906@oracle.com> <0702b6e5-cc4a-3dc8-74cf-f7edd3c716d3@oracle.com> <50663F6E-F9C7-4075-8A7A-ACDD5CF5A5B0@oracle.com> <330d4889-a7bb-0294-bed5-f58c944adac9@oracle.com> <B807EF9A-88A0-4551-92F9-5A1920A8DAED@oracle.com> <2D5F20B6-B2F4-493F-A518-410C432BF3D9@oracle.com> <782a2b23-9ddd-0730-38c3-ce77f4a4bdad@oracle.com> <6A37AD7E-1EE0-49D5-8A87-506B081A7164@oracle.com> <EBCF595C-E6D9-4FF3-A9FC-13651E5DD5C5@oracle.com> <0c2c3fa6-66de-18ac-440b-35c68c0336c1@oracle.com> <413ACCD0-D8F5-49CD-B614-779C96A8E44B@oracle.com> Message-ID: <3E76463E-B145-495E-9CBD-6B7837D4A4FC@oracle.com> On May 30, 2018, at 7:25 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote: > On May 30, 2018, at 12:19 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > >> Good, I think this is the right approach as it re-works the test now as the issues are clear. A few comments: > > It was an excellent idea - thanks. > >> - no need to add the intermittent tag, that may be left over from your original patch > > Shall excise. > >> - most of the comment on mightHoldKeySetLock can be replaced with a comment to say that selection operations are specified to synchronize on the selected key set. > > I realize it?s overkill. I was clarifying it for myself. > >> Also there is nothing in this method that knows anything about selector or the selected-key set so it could be renamed (to drop "KeySet") and the comment can be moved to the while loop in main where it calls the method with the selected-key set. > > Yes, I thought of that. > >> - no need for the try/catch around selector.close, it's okay to have the main method throw IOException > > Will change before the push. All suggested changes have been made [1] and tested on all platforms. In addition I removed the ?closed? variable and the testing of it as it now seems pointless. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8203765/webrev.03/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180530/17259b21/attachment.html> From Alan.Bateman at oracle.com Thu May 31 10:05:36 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 May 2018 11:05:36 +0100 Subject: 8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag In-Reply-To: <3E76463E-B145-495E-9CBD-6B7837D4A4FC@oracle.com> References: <934E8230-8A21-4C59-AFD3-B7480ECCC906@oracle.com> <0702b6e5-cc4a-3dc8-74cf-f7edd3c716d3@oracle.com> <50663F6E-F9C7-4075-8A7A-ACDD5CF5A5B0@oracle.com> <330d4889-a7bb-0294-bed5-f58c944adac9@oracle.com> <B807EF9A-88A0-4551-92F9-5A1920A8DAED@oracle.com> <2D5F20B6-B2F4-493F-A518-410C432BF3D9@oracle.com> <782a2b23-9ddd-0730-38c3-ce77f4a4bdad@oracle.com> <6A37AD7E-1EE0-49D5-8A87-506B081A7164@oracle.com> <EBCF595C-E6D9-4FF3-A9FC-13651E5DD5C5@oracle.com> <0c2c3fa6-66de-18ac-440b-35c68c0336c1@oracle.com> <413ACCD0-D8F5-49CD-B614-779C96A8E44B@oracle.com> <3E76463E-B145-495E-9CBD-6B7837D4A4FC@oracle.com> Message-ID: <b9f006d0-e38f-6093-6b67-34b159f1dc7f@oracle.com> On 30/05/2018 21:56, Brian Burkhalter wrote: > All suggested changes have been made [1] and tested on all platforms. > In addition I removed the ?closed? variable and the testing of it as > it now seems pointless. > Looks good. -Alan From Alan.Bateman at oracle.com Thu May 31 12:25:57 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 May 2018 13:25:57 +0100 Subject: [PATCH] 6350055: Atomic SelectionKey operations In-Reply-To: <CANghgrSg01jccDXDFU8U=io5nP7gL6DUsBbfedjFY1T8x1Wavw@mail.gmail.com> References: <CANghgrRgWCR2QnFoH=+tTDwaV1th7W+jHNntXy-QhaD4rZDAEQ@mail.gmail.com> <fa4221ae-fafe-317d-f82f-855966795665@oracle.com> <CANghgrRVpm5HAgV4V-z-uiGCYDz+Ru00fy2s+8U-r-qNZxAM-A@mail.gmail.com> <d434891a-9c19-11f1-1192-32b5add61b8c@oracle.com> <CANghgrQDC-3CRCaiQ7_SxUwq9krMZOuaMHbpZm=F7pDAO7Fsxw@mail.gmail.com> <CANghgrSg01jccDXDFU8U=io5nP7gL6DUsBbfedjFY1T8x1Wavw@mail.gmail.com> Message-ID: <3bd9bdad-5d83-2974-2644-c4400f36df7e@oracle.com> On 30/05/2018 19:14, David Lloyd wrote: > On Wed, May 23, 2018 at 9:00 AM, David Lloyd <david.lloyd at redhat.com> wrote: >> I can probably add tests to show that the ops work. I'm not so sure >> that I can make a test that proves the atomicity of the operation >> though. > Updated with tests [1] & attached. > I quickly skimmed it and the test look reasonable. We should extend it to cover the CancelledKeyException and IllegaArgumentException cases too, I didn't spot anything testing these exceptions. -Alan From david.lloyd at redhat.com Thu May 31 14:52:02 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 31 May 2018 09:52:02 -0500 Subject: [PATCH] 6350055: Atomic SelectionKey operations In-Reply-To: <3bd9bdad-5d83-2974-2644-c4400f36df7e@oracle.com> References: <CANghgrRgWCR2QnFoH=+tTDwaV1th7W+jHNntXy-QhaD4rZDAEQ@mail.gmail.com> <fa4221ae-fafe-317d-f82f-855966795665@oracle.com> <CANghgrRVpm5HAgV4V-z-uiGCYDz+Ru00fy2s+8U-r-qNZxAM-A@mail.gmail.com> <d434891a-9c19-11f1-1192-32b5add61b8c@oracle.com> <CANghgrQDC-3CRCaiQ7_SxUwq9krMZOuaMHbpZm=F7pDAO7Fsxw@mail.gmail.com> <CANghgrSg01jccDXDFU8U=io5nP7gL6DUsBbfedjFY1T8x1Wavw@mail.gmail.com> <3bd9bdad-5d83-2974-2644-c4400f36df7e@oracle.com> Message-ID: <CANghgrRL_w730xd61RggJmMbducmQ6s+B558F1Hq7Uw_jmu=OQ@mail.gmail.com> The testNioImplementation method covers IllegalArgumentException, but I can add tests for CancelledKeyException easily... On Thu, May 31, 2018 at 7:25 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: > > > On 30/05/2018 19:14, David Lloyd wrote: >> >> On Wed, May 23, 2018 at 9:00 AM, David Lloyd <david.lloyd at redhat.com> >> wrote: >>> >>> I can probably add tests to show that the ops work. I'm not so sure >>> that I can make a test that proves the atomicity of the operation >>> though. >> >> Updated with tests [1] & attached. >> > I quickly skimmed it and the test look reasonable. We should extend it to > cover the CancelledKeyException and IllegaArgumentException cases too, I > didn't spot anything testing these exceptions. > > -Alan -- - DML From david.lloyd at redhat.com Thu May 31 14:55:02 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 31 May 2018 09:55:02 -0500 Subject: [PATCH] 6350055: Atomic SelectionKey operations In-Reply-To: <CANghgrRL_w730xd61RggJmMbducmQ6s+B558F1Hq7Uw_jmu=OQ@mail.gmail.com> References: <CANghgrRgWCR2QnFoH=+tTDwaV1th7W+jHNntXy-QhaD4rZDAEQ@mail.gmail.com> <fa4221ae-fafe-317d-f82f-855966795665@oracle.com> <CANghgrRVpm5HAgV4V-z-uiGCYDz+Ru00fy2s+8U-r-qNZxAM-A@mail.gmail.com> <d434891a-9c19-11f1-1192-32b5add61b8c@oracle.com> <CANghgrQDC-3CRCaiQ7_SxUwq9krMZOuaMHbpZm=F7pDAO7Fsxw@mail.gmail.com> <CANghgrSg01jccDXDFU8U=io5nP7gL6DUsBbfedjFY1T8x1Wavw@mail.gmail.com> <3bd9bdad-5d83-2974-2644-c4400f36df7e@oracle.com> <CANghgrRL_w730xd61RggJmMbducmQ6s+B558F1Hq7Uw_jmu=OQ@mail.gmail.com> Message-ID: <CANghgrQbs3bpH=kCK5+zGP7eaqQ3W2OJ24sY75KW_A=DmrgeXQ@mail.gmail.com> And here [1] it is. [1] https://github.com/dmlloyd/openjdk/commit/atomic-nio-ops-v9 On Thu, May 31, 2018 at 9:52 AM, David Lloyd <david.lloyd at redhat.com> wrote: > The testNioImplementation method covers IllegalArgumentException, but > I can add tests for CancelledKeyException easily... > > On Thu, May 31, 2018 at 7:25 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote: >> >> >> On 30/05/2018 19:14, David Lloyd wrote: >>> >>> On Wed, May 23, 2018 at 9:00 AM, David Lloyd <david.lloyd at redhat.com> >>> wrote: >>>> >>>> I can probably add tests to show that the ops work. I'm not so sure >>>> that I can make a test that proves the atomicity of the operation >>>> though. >>> >>> Updated with tests [1] & attached. >>> >> I quickly skimmed it and the test look reasonable. We should extend it to >> cover the CancelledKeyException and IllegaArgumentException cases too, I >> didn't spot anything testing these exceptions. >> >> -Alan > > > > -- > - DML -- - DML -------------- next part -------------- commit 9469d5482558fc79e6ddbc2e84856431de213c44 Author: David M. Lloyd <david.lloyd at redhat.com> Date: Wed Mar 28 13:13:44 2018 -0500 [JDK-6350055] Add atomic interest op methods to SelectionKey diff --git a/src/java.base/share/classes/java/nio/channels/SelectionKey.java b/src/java.base/share/classes/java/nio/channels/SelectionKey.java index ad08fe43822..cfc4faeae8e 100644 --- a/src/java.base/share/classes/java/nio/channels/SelectionKey.java +++ b/src/java.base/share/classes/java/nio/channels/SelectionKey.java @@ -189,6 +189,86 @@ public abstract class SelectionKey { */ public abstract SelectionKey interestOps(int ops); + /** + * Atomically sets this key's interest set to bitwise union ("or") of the existing + * interest set and the given value. This method is guaranteed to be + * atomic with respect to other concurrent calls to this method or to + * {@link #interestOpsAnd(int)}. + * + * <p> This method may be invoked at any time. If this method is invoked + * while a selection operation is in progress then it has no effect upon + * that operation; the change to the key's interest set will be seen by the + * next selection operation. + * + * @param ops The interest set to apply + * + * @return The previous interest set + * + * @throws IllegalArgumentException + * If a bit in the resultant set does not correspond to an operation that + * is supported by this key's channel, that is, if + * {@code ((interestOps() | ops) & ~channel().validOps()) != 0} + * + * @throws CancelledKeyException + * If this key has been cancelled + * + * @implSpec The default implementation synchronizes on this {@code SelectionKey} + * instance, calling {@link #interestOps()} and {@link #interestOps(int)} + * in turn; subclasses should provide a better implementation if + * possible (for example, using a + * {@link java.lang.invoke.VarHandle VarHandle} may be appropriate). + */ + public int interestOpsOr(int ops) { + synchronized (this) { + int oldVal = interestOps(); + interestOps(oldVal | ops); + return oldVal; + } + } + + /** + * Atomically sets this key's interest set to bitwise intersection ("and") of the + * existing interest set and the given value. This method is guaranteed to be + * atomic with respect to other concurrent calls to this method or to + * {@link #interestOpsOr(int)}. + * + * <p> This method may be invoked at any time. If this method is invoked + * while a selection operation is in progress then it has no effect upon + * that operation; the change to the key's interest set will be seen by the + * next selection operation. + * + * @param ops The interest set to apply + * + * @return The previous interest set + * + * @throws IllegalArgumentException + * If a bit in the resultant set does not correspond to an operation that + * is supported by this key's channel, that is, if + * {@code (interestOps() & ops & ~channel().validOps()) != 0} + * + * @throws CancelledKeyException + * If this key has been cancelled + * + * @apiNote The {@code ops} argument may contain bits which are not normally + * allowed by this key's channel, allowing bits to be cleared using + * bitwise complement values. For example, + * {@code interestOpsAnd(~SelectionKey.OP_READ)} will remove the + * {@code OP_READ} bit from the set without affecting other bits. + * + * @implSpec The default implementation synchronizes on this {@code SelectionKey} + * instance, calling {@link #interestOps()} and {@link #interestOps(int)} + * in turn; subclasses should provide a better implementation if + * possible (for example, using a + * {@link java.lang.invoke.VarHandle VarHandle} may be appropriate). + */ + public int interestOpsAnd(int ops) { + synchronized (this) { + int oldVal = interestOps(); + interestOps(oldVal & ops); + return oldVal; + } + } + /** * Retrieves this key's ready-operation set. * diff --git a/src/java.base/share/classes/sun/nio/ch/SelectionKeyImpl.java b/src/java.base/share/classes/sun/nio/ch/SelectionKeyImpl.java index 2f917c8d2e3..26b2afe2f08 100644 --- a/src/java.base/share/classes/sun/nio/ch/SelectionKeyImpl.java +++ b/src/java.base/share/classes/sun/nio/ch/SelectionKeyImpl.java @@ -25,6 +25,9 @@ package sun.nio.ch; +import java.lang.invoke.ConstantBootstraps; +import java.lang.invoke.MethodHandles; +import java.lang.invoke.VarHandle; import java.nio.channels.CancelledKeyException; import java.nio.channels.SelectableChannel; import java.nio.channels.SelectionKey; @@ -42,6 +45,10 @@ public final class SelectionKeyImpl private final SelChImpl channel; private final SelectorImpl selector; + private static final VarHandle interestOpsHandle = ConstantBootstraps.fieldVarHandle( + MethodHandles.lookup(), "interestOps", VarHandle.class, SelectionKeyImpl.class, int.class + ); + private volatile int interestOps; private volatile int readyOps; @@ -84,7 +91,35 @@ public final class SelectionKeyImpl @Override public SelectionKey interestOps(int ops) { ensureValid(); - return nioInterestOps(ops); + if ((ops & ~channel().validOps()) != 0) + throw new IllegalArgumentException(); + int oldOps = (int) interestOpsHandle.getAndSet(this, ops); + if (ops != oldOps) { + selector.setEventOps(this); + } + return this; + } + + @Override + public int interestOpsOr(final int ops) { + ensureValid(); + if ((ops & ~channel().validOps()) != 0) + throw new IllegalArgumentException(); + int oldVal = (int) interestOpsHandle.getAndBitwiseOr(this, ops); + if (oldVal != (oldVal | ops)) { + selector.setEventOps(this); + } + return oldVal; + } + + @Override + public int interestOpsAnd(final int ops) { + ensureValid(); + int oldVal = (int) interestOpsHandle.getAndBitwiseAnd(this, ops); + if (oldVal != (oldVal & ops)) { + selector.setEventOps(this); + } + return oldVal; } @Override diff --git a/test/jdk/java/nio/channels/Selector/AtomicSelectionKeyOps.java b/test/jdk/java/nio/channels/Selector/AtomicSelectionKeyOps.java new file mode 100644 index 00000000000..4c11e92aa22 --- /dev/null +++ b/test/jdk/java/nio/channels/Selector/AtomicSelectionKeyOps.java @@ -0,0 +1,165 @@ +/* + * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Oracle designates this + * particular file as subject to the "Classpath" exception as provided + * by Oracle in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* @test + * @run testng ValidateSelectionKeyOps + * @summary Test that the operations on SelectionKey function as specified. + */ + +import java.io.Closeable; +import java.io.IOException; +import java.net.InetAddress; +import java.net.InetSocketAddress; +import java.nio.channels.CancelledKeyException; +import java.nio.channels.SelectableChannel; +import java.nio.channels.SelectionKey; +import java.nio.channels.Selector; +import java.nio.channels.ServerSocketChannel; +import java.nio.channels.SocketChannel; +import org.testng.annotations.Test; + +import static java.nio.channels.SelectionKey.OP_READ; +import static java.nio.channels.SelectionKey.OP_WRITE; +import static java.nio.channels.SelectionKey.OP_CONNECT; +import static java.nio.channels.SelectionKey.OP_ACCEPT; +import static org.testng.Assert.*; + + at Test +public class AtomicSelectionKeyOps { + + public void testBaseImplementation() throws Exception { + SelectionKey testKeyImpl = new SelectionKey() { + private int ops; + + public SelectableChannel channel() { + return null; + } + + public Selector selector() { + return null; + } + + public boolean isValid() { + return true; + } + + public void cancel() { + } + + public int interestOps() { + return ops; + } + + public SelectionKey interestOps(final int ops) { + this.ops = ops; + return this; + } + + public int readyOps() { + return 0; + } + }; + + assertEquals(testKeyImpl.interestOps(), 0); + testKeyImpl.interestOps(OP_READ); + assertEquals(testKeyImpl.interestOps(), OP_READ); + testKeyImpl.interestOpsOr(OP_ACCEPT | OP_WRITE); + assertEquals(testKeyImpl.interestOps(), OP_READ | OP_WRITE | OP_ACCEPT); + testKeyImpl.interestOpsAnd(OP_WRITE | OP_CONNECT); + assertEquals(testKeyImpl.interestOps(), OP_WRITE); + testKeyImpl.interestOpsOr(OP_CONNECT); + assertEquals(testKeyImpl.interestOps(), OP_WRITE | OP_CONNECT); + testKeyImpl.interestOpsAnd(OP_READ); + assertEquals(testKeyImpl.interestOps(), 0); + } + + public void testNioImplementation() throws Exception { + final Selector selector = Selector.open(); + final ConnectionPair pair = new ConnectionPair(); + final SocketChannel channel = pair.channel1(); + channel.configureBlocking(false); + final SelectionKey selectionKey = channel.register(selector, 0); + assertEquals(selectionKey.interestOps(), 0); + selectionKey.interestOps(OP_READ); + assertEquals(selectionKey.interestOps(), OP_READ); + try { + selectionKey.interestOpsOr(OP_ACCEPT | OP_WRITE); + fail("Expected exception"); + } catch (IllegalArgumentException okay) {} + selectionKey.interestOpsAnd(OP_ACCEPT | OP_READ); // no failure + assertEquals(selectionKey.interestOps(), OP_READ); + selectionKey.interestOpsOr(OP_WRITE); + assertEquals(selectionKey.interestOps(), OP_READ | OP_WRITE); + selectionKey.interestOpsAnd(OP_WRITE | OP_CONNECT); + assertEquals(selectionKey.interestOps(), OP_WRITE); + selectionKey.interestOpsOr(OP_CONNECT); + assertEquals(selectionKey.interestOps(), OP_WRITE | OP_CONNECT); + selectionKey.interestOpsAnd(OP_READ); + assertEquals(selectionKey.interestOps(), 0); + selectionKey.cancel(); + try { + selectionKey.interestOps(OP_READ); // baseline + fail("Expected exception"); + } catch (CancelledKeyException okay) {} + try { + selectionKey.interestOpsAnd(OP_READ); + fail("Expected exception"); + } catch (CancelledKeyException okay) {} + try { + selectionKey.interestOpsOr(OP_READ); + fail("Expected exception"); + } catch (CancelledKeyException okay) {} + pair.close(); + } + + static class ConnectionPair implements Closeable { + + private final SocketChannel sc1; + private final SocketChannel sc2; + + ConnectionPair() throws IOException { + InetAddress lb = InetAddress.getLoopbackAddress(); + try (ServerSocketChannel ssc = ServerSocketChannel.open()) { + ssc.bind(new InetSocketAddress(lb, 0)); + this.sc1 = SocketChannel.open(ssc.getLocalAddress()); + this.sc2 = ssc.accept(); + } + } + + SocketChannel channel1() { + return sc1; + } + + SocketChannel channel2() { + return sc2; + } + + public void close() throws IOException { + sc1.close(); + sc2.close(); + } + } +} +