Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly
Add core-libs. Thanks, Felix On 2016/12/5 22:14, Felix Yang wrote: Hi, updated webrev. May I have a reviewer to review this http://cr.openjdk.java.net/~xiaofeya/8043838/webrev.01/ -Felix On 2016/12/5 15:50, Felix Yang wrote: On 2016/12/5 15:47, Langer, Christoph wrote: Hi Felix, looks ok to me. You probably should remove the reference to the old shell script in comment line 25, though: 25 * Test run from script, AcceptCauseFileDescriptorLeak.sh Christoph, Good catch! Thanks, Felix Best regards Christoph
JEP 110 HTTP client API
Hi, I just want to confirm the plans for the HTTP client API in JDK 9 that were hinted at previously. There is a new feature called "incubator modules" which has just been proposed for JDK 9. The idea is to accommodate new APIs in JDK which are not quite ready to be standardized as part of Java SE. There is more information at the link below [1]. But, the main implications are: - the API package namespace must be under jdk.incubator - the API is not a standard part of the platform and is subject to change before being standardized in a future release of JDK. - compile time and run time warnings are issued when using the feature. - the feature is not visible by default but must be opted into with a command line option. The plan is for the new httpclient API to be included with JDK 9 using this feature. Therefore, the package java.net.http will be renamed as jdk.incubator.http in JDK 9, and the implementation will reside in its own module also under the jdk.incubator namespace. The aim is to gain experience with the API, and standardize it for JDK 10 by moving it back from jdk.incubator.http to java.net.http together with any other API changes as a result of that experience. Bug id 8169768 [2] has been filed to handle the change and the plan is to integrate the work that has been done in the sandbox forest using the JEP 11 guidelines, into jdk9 dev, by the end of this week. We will publish a webrev of the changes in the next day or two. I will update the JEP 110 description [3] to reflect these changes in the next day or two. Thanks, Michael. [1] (Incubator modules JEP 11) https://bugs.openjdk.java.net/browse/JDK-8169768 [2] (bug to update JEP 110) https://bugs.openjdk.java.net/browse/JDK-8169768 [3] (JEP 110) https://bugs.openjdk.java.net/browse/JDK-8042950
Re: Special exception for EMFILE / ENFILE when using sockets.
Hello, I know it is a radical idea, but what about exposing errno value in an IOException. I do think that the new ConnectionRefused subtype is helpful, but for each seldomly occuring error case a dedicated exception is more work than a one time mapping of native errormcodes to fields. Gruss Bernd -- http://bernd.eckenfels.net On Mon, Dec 5, 2016 at 7:28 PM +0100, "Norman Maurer" wrote: > Am 05.12.2016 um 18:48 schrieb David M. Lloyd : > >> On 12/05/2016 06:29 AM, Norman Maurer wrote: >> Hi all, >> >> I wonder if it would be possible to add a new public exception time for the >> situation of an SocketChannel.accept(…) or SocketChannel.open(…) (and the >> same for ServerSocket / Socket) failing because of too many open files. >> The reason is because especially when acting as a server such an exception >> may be something you can easily recover from. At there is basically no way >> to detect if this was the cause of an IOException or not. >> >> On unix / linux this are the errno values: >> >> [EMFILE] The per-process descriptor table is full. >> [ENFILE] The system file table is full. >> >> For netty we would love to be able to know if this was the case of the >> problem and if so just stop accepting for a period of time to help the >> system to recover. >> >> What others think about this ? > > I like the idea, but maybe it should be a general IOException since this same > error can happen on file open, selector creation (sometimes), pipe creation, > etc. > > -- > - DML Sure that would work for me as well :) Bye, Norman
Re: Special exception for EMFILE / ENFILE when using sockets.
> Am 05.12.2016 um 18:48 schrieb David M. Lloyd : > >> On 12/05/2016 06:29 AM, Norman Maurer wrote: >> Hi all, >> >> I wonder if it would be possible to add a new public exception time for the >> situation of an SocketChannel.accept(…) or SocketChannel.open(…) (and the >> same for ServerSocket / Socket) failing because of too many open files. >> The reason is because especially when acting as a server such an exception >> may be something you can easily recover from. At there is basically no way >> to detect if this was the cause of an IOException or not. >> >> On unix / linux this are the errno values: >> >> [EMFILE] The per-process descriptor table is full. >> [ENFILE] The system file table is full. >> >> For netty we would love to be able to know if this was the case of the >> problem and if so just stop accepting for a period of time to help the >> system to recover. >> >> What others think about this ? > > I like the idea, but maybe it should be a general IOException since this same > error can happen on file open, selector creation (sometimes), pipe creation, > etc. > > -- > - DML Sure that would work for me as well :) Bye, Norman
Re: Special exception for EMFILE / ENFILE when using sockets.
On 12/05/2016 06:29 AM, Norman Maurer wrote: Hi all, I wonder if it would be possible to add a new public exception time for the situation of an SocketChannel.accept(…) or SocketChannel.open(…) (and the same for ServerSocket / Socket) failing because of too many open files. The reason is because especially when acting as a server such an exception may be something you can easily recover from. At there is basically no way to detect if this was the cause of an IOException or not. On unix / linux this are the errno values: [EMFILE] The per-process descriptor table is full. [ENFILE] The system file table is full. For netty we would love to be able to know if this was the case of the problem and if so just stop accepting for a period of time to help the system to recover. What others think about this ? I like the idea, but maybe it should be a general IOException since this same error can happen on file open, selector creation (sometimes), pipe creation, etc. -- - DML
Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly
Hi, updated webrev. May I have a reviewer to review this http://cr.openjdk.java.net/~xiaofeya/8043838/webrev.01/ -Felix On 2016/12/5 15:50, Felix Yang wrote: On 2016/12/5 15:47, Langer, Christoph wrote: Hi Felix, looks ok to me. You probably should remove the reference to the old shell script in comment line 25, though: 25 * Test run from script, AcceptCauseFileDescriptorLeak.sh Christoph, Good catch! Thanks, Felix Best regards Christoph
Special exception for EMFILE / ENFILE when using sockets.
Hi all, I wonder if it would be possible to add a new public exception time for the situation of an SocketChannel.accept(…) or SocketChannel.open(…) (and the same for ServerSocket / Socket) failing because of too many open files. The reason is because especially when acting as a server such an exception may be something you can easily recover from. At there is basically no way to detect if this was the cause of an IOException or not. On unix / linux this are the errno values: [EMFILE] The per-process descriptor table is full. [ENFILE] The system file table is full. For netty we would love to be able to know if this was the case of the problem and if so just stop accepting for a period of time to help the system to recover. What others think about this ? Thanks, Norman
