From huaming.li at oracle.com Tue Apr 5 12:03:52 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 5 Apr 2016 20:03:52 +0800 Subject: JDK 9 RFR of JDK-8068693/8153209: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing Message-ID: <5703A9A8.1050803@oracle.com> Would you please review the patch for test java/nio/channels/AsyncCloseAndInterrupt.java? There are 2 test issues, JDK-8068693, JDK-8153209 (java/nio/channels/AsyncCloseAndInterrupt.java fails throwing exception: java.nio.channels.ClosedChannelException). Root cause: for JDK-8068693, 500ms is too short on busy system for channel to be closed or for thread blocking on IO to be interrupted. for JDK-8153209, it's a test regression due to JDK-8151582 (http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/88577677aec9). There is a time window between thread ready and io operation ready, deleting the original sleep(100) might cause channel closed before accessing the channel. Suggested Fix: for JDK-8068693, increase the time from 500ms to 10000ms. for JDK-8153209, do not sleep when running tests for CONNECT/FINISH_CONNECT, sleep for other test cases. bug: https://bugs.openjdk.java.net/browse/JDK-8068693, https://bugs.openjdk.java.net/browse/JDK-8153209 webrev: http://cr.openjdk.java.net/~mli/8068693/webrev.00/ Thank you -Hamlin From martinrb at google.com Tue Apr 5 17:23:30 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Apr 2016 10:23:30 -0700 Subject: JDK 9 RFR of JDK-8068693/8153209: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing In-Reply-To: <5703A9A8.1050803@oracle.com> References: <5703A9A8.1050803@oracle.com> Message-ID: The use of sleeps in these tests is disturbing. Occasionally they're necessary, but usually they can be removed. For example 574 do { 575 sleep(50); 576 } while (!t.ready); Instead of making ready a volatile flag and spin-sleeping, make it a CountDownLatch that you can await On Tue, Apr 5, 2016 at 5:03 AM, Hamlin Li wrote: > Would you please review the patch for test > java/nio/channels/AsyncCloseAndInterrupt.java? > > There are 2 test issues, JDK-8068693, JDK-8153209 > (java/nio/channels/AsyncCloseAndInterrupt.java fails throwing exception: > java.nio.channels.ClosedChannelException). > Root cause: > for JDK-8068693, 500ms is too short on busy system for channel to be > closed or for thread blocking on IO to be interrupted. > for JDK-8153209, it's a test regression due to JDK-8151582 > (http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/88577677aec9). There is a time > window between thread ready and io operation ready, deleting the original > sleep(100) might cause channel closed before accessing the channel. > Suggested Fix: > for JDK-8068693, increase the time from 500ms to 10000ms. > for JDK-8153209, do not sleep when running tests for > CONNECT/FINISH_CONNECT, sleep for other test cases. > > bug: https://bugs.openjdk.java.net/browse/JDK-8068693, > https://bugs.openjdk.java.net/browse/JDK-8153209 > webrev: http://cr.openjdk.java.net/~mli/8068693/webrev.00/ > > Thank you > -Hamlin From huaming.li at oracle.com Wed Apr 6 01:26:57 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 6 Apr 2016 09:26:57 +0800 Subject: JDK 9 RFR of JDK-8068693/8153209: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing In-Reply-To: References: <5703A9A8.1050803@oracle.com> Message-ID: <570465E1.7050008@oracle.com> Hi Martin, Thanks for reviewing, please check my comments inline. -Hamlin On 2016/4/6 1:23, Martin Buchholz wrote: > The use of sleeps in these tests is disturbing. Occasionally they're > necessary, but usually they can be removed. For example > > 574 do { > 575 sleep(50); > 576 } while (!t.ready); Yes, agree with you. But as this piece of code is legacy code, and does not cause any testing issue, so I choose to keep it. > > Instead of making ready a volatile flag and spin-sleeping, make it a > CountDownLatch that you can await > > > On Tue, Apr 5, 2016 at 5:03 AM, Hamlin Li wrote: >> Would you please review the patch for test >> java/nio/channels/AsyncCloseAndInterrupt.java? >> >> There are 2 test issues, JDK-8068693, JDK-8153209 >> (java/nio/channels/AsyncCloseAndInterrupt.java fails throwing exception: >> java.nio.channels.ClosedChannelException). >> Root cause: >> for JDK-8068693, 500ms is too short on busy system for channel to be >> closed or for thread blocking on IO to be interrupted. >> for JDK-8153209, it's a test regression due to JDK-8151582 >> (http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/88577677aec9). There is a time >> window between thread ready and io operation ready, deleting the original >> sleep(100) might cause channel closed before accessing the channel. >> Suggested Fix: >> for JDK-8068693, increase the time from 500ms to 10000ms. >> for JDK-8153209, do not sleep when running tests for >> CONNECT/FINISH_CONNECT, sleep for other test cases. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8068693, >> https://bugs.openjdk.java.net/browse/JDK-8153209 >> webrev: http://cr.openjdk.java.net/~mli/8068693/webrev.00/ >> >> Thank you >> -Hamlin From martinrb at google.com Wed Apr 6 02:01:16 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Apr 2016 19:01:16 -0700 Subject: JDK 9 RFR of JDK-8068693/8153209: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing In-Reply-To: <570465E1.7050008@oracle.com> References: <5703A9A8.1050803@oracle.com> <570465E1.7050008@oracle.com> Message-ID: On Tue, Apr 5, 2016 at 6:26 PM, Hamlin Li wrote: > Hi Martin, > Thanks for reviewing, please check my comments inline. > > -Hamlin > > On 2016/4/6 1:23, Martin Buchholz wrote: >> >> The use of sleeps in these tests is disturbing. Occasionally they're >> necessary, but usually they can be removed. For example >> >> 574 do { >> 575 sleep(50); >> 576 } while (!t.ready); > > Yes, agree with you. But as this piece of code is legacy code, and does not > cause any testing issue, so I choose to keep it. Well, yes, but you are introducing a new sleep(100). My own experience is that 100ms is never long enough to wait for any other thread to do something. But this is just a drive by comment - I don't understand this code enough to understand the purpose of the sleep. From huaming.li at oracle.com Wed Apr 6 02:20:30 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 6 Apr 2016 10:20:30 +0800 Subject: JDK 9 RFR of JDK-8068693/8153209: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing In-Reply-To: References: <5703A9A8.1050803@oracle.com> <570465E1.7050008@oracle.com> Message-ID: <5704726E.1050704@oracle.com> On 2016/4/6 10:01, Martin Buchholz wrote: > On Tue, Apr 5, 2016 at 6:26 PM, Hamlin Li wrote: >> Hi Martin, >> Thanks for reviewing, please check my comments inline. >> >> -Hamlin >> >> On 2016/4/6 1:23, Martin Buchholz wrote: >>> The use of sleeps in these tests is disturbing. Occasionally they're >>> necessary, but usually they can be removed. For example >>> >>> 574 do { >>> 575 sleep(50); >>> 576 } while (!t.ready); >> Yes, agree with you. But as this piece of code is legacy code, and does not >> cause any testing issue, so I choose to keep it. > Well, yes, but you are introducing a new sleep(100). > > My own experience is that 100ms is never long enough to wait for any > other thread to do something. But this is just a drive by comment - I > don't understand this code enough to understand the purpose of the > sleep. Hi Martin, ( There is a little bit long history, it involves 3 bugs https://bugs.openjdk.java.net/browse/JDK-8151582, https://bugs.openjdk.java.net/browse/JDK-8068693, https://bugs.openjdk.java.net/browse/JDK-8153209. ) No, this(sleep(100)) is not introduced by me, it's deleted in another fix where I tried to fix another issue (https://bugs.openjdk.java.net/browse/JDK-8151582, http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/88577677aec9), but seems the fix introduced a new issue(https://bugs.openjdk.java.net/browse/JDK-8153209) which never occurred before. so sleep(100) is in fact kind of an rollback rather than introducing new code. And, even if we use CountDownLatch to wait, I'm afraid it will not work exactly as expected, below is a briefing: in thread_main, 1. launch thread_2 2. wait (sleep or CountDownLatch) until thread_2 get into a blocking io operation such as reading a socket 3. call close/interrupt ... in thread 2, 1. before get to the reading operation, notify thread_main 2. get into the blocking io operation But there is still a time window between step 3 in main_thread, and step 2 in thread_2, so I don't think CountDownLatch will solve the issue perfectly. As this new issue(https://bugs.openjdk.java.net/browse/JDK-8153209) never occur before, so I think the best way to fix it is to keep the original code for the new failing test cases reported in https://bugs.openjdk.java.net/browse/JDK-8153209, and introducing the new code(not calling sleep(100)) for the failing test cases reported in https://bugs.openjdk.java.net/browse/JDK-8151582. Thank you -Hamlin From martinrb at google.com Wed Apr 6 03:35:22 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Apr 2016 20:35:22 -0700 Subject: JDK 9 RFR of JDK-8068693/8153209: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing In-Reply-To: <5704726E.1050704@oracle.com> References: <5703A9A8.1050803@oracle.com> <570465E1.7050008@oracle.com> <5704726E.1050704@oracle.com> Message-ID: Thanks for the explanation. We occasionally have essentially the same tough problem in j.u.concurrent. Sometimes you can monitor the target thread (e.g. Thread.STATE) and spin-wait. For blocking in I/O, the OS might know, but then you have system dependent code to query it. If you sleep for 100ms, it will sometimes not be enough and you will have (too many) sporadic flakes. if you sleep for 10seconds, it will almost surely be enough, but that's a very long time for a test. Sometimes the only reasonable solution is to keep retrying with ever increasing sleeps up to e.g. 10 seconds. Then the test will almost always run fast and still (almost) never flake. I'm still not your real reviewer. On Tue, Apr 5, 2016 at 7:20 PM, Hamlin Li wrote: > > > On 2016/4/6 10:01, Martin Buchholz wrote: >> >> On Tue, Apr 5, 2016 at 6:26 PM, Hamlin Li wrote: >>> >>> Hi Martin, >>> Thanks for reviewing, please check my comments inline. >>> >>> -Hamlin >>> >>> On 2016/4/6 1:23, Martin Buchholz wrote: >>>> >>>> The use of sleeps in these tests is disturbing. Occasionally they're >>>> necessary, but usually they can be removed. For example >>>> >>>> 574 do { >>>> 575 sleep(50); >>>> 576 } while (!t.ready); >>> >>> Yes, agree with you. But as this piece of code is legacy code, and does >>> not >>> cause any testing issue, so I choose to keep it. >> >> Well, yes, but you are introducing a new sleep(100). >> >> My own experience is that 100ms is never long enough to wait for any >> other thread to do something. But this is just a drive by comment - I >> don't understand this code enough to understand the purpose of the >> sleep. > > Hi Martin, > > ( There is a little bit long history, it involves 3 bugs > https://bugs.openjdk.java.net/browse/JDK-8151582, > https://bugs.openjdk.java.net/browse/JDK-8068693, > https://bugs.openjdk.java.net/browse/JDK-8153209. ) > > No, this(sleep(100)) is not introduced by me, it's deleted in another fix > where I tried to fix another issue > (https://bugs.openjdk.java.net/browse/JDK-8151582, > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/88577677aec9), but seems the > fix introduced a new issue(https://bugs.openjdk.java.net/browse/JDK-8153209) > which never occurred before. so sleep(100) is in fact kind of an rollback > rather than introducing new code. > And, even if we use CountDownLatch to wait, I'm afraid it will not work > exactly as expected, below is a briefing: > in thread_main, > 1. launch thread_2 > 2. wait (sleep or CountDownLatch) until thread_2 get into a blocking io > operation such as reading a socket > 3. call close/interrupt ... > in thread 2, > 1. before get to the reading operation, notify thread_main > 2. get into the blocking io operation > But there is still a time window between step 3 in main_thread, and step 2 > in thread_2, so I don't think CountDownLatch will solve the issue perfectly. > As this new issue(https://bugs.openjdk.java.net/browse/JDK-8153209) never > occur before, so I think the best way to fix it is to keep the original code > for the new failing test cases reported in > https://bugs.openjdk.java.net/browse/JDK-8153209, and introducing the new > code(not calling sleep(100)) for the failing test cases reported in > https://bugs.openjdk.java.net/browse/JDK-8151582. > > Thank you > -Hamlin > From huaming.li at oracle.com Wed Apr 6 03:43:38 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 6 Apr 2016 11:43:38 +0800 Subject: JDK 9 RFR of JDK-8068693/8153209: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing In-Reply-To: References: <5703A9A8.1050803@oracle.com> <570465E1.7050008@oracle.com> <5704726E.1050704@oracle.com> Message-ID: <570485EA.3000608@oracle.com> On 2016/4/6 11:35, Martin Buchholz wrote: > Thanks for the explanation. We occasionally have essentially the same > tough problem in j.u.concurrent. > Sometimes you can monitor the target thread (e.g. Thread.STATE) and spin-wait. > For blocking in I/O, the OS might know, but then you have system > dependent code to query it. > If you sleep for 100ms, it will sometimes not be enough and you will > have (too many) sporadic flakes. > if you sleep for 10seconds, it will almost surely be enough, but > that's a very long time for a test. > Sometimes the only reasonable solution is to keep retrying with ever > increasing sleeps up to e.g. 10 seconds. > Then the test will almost always run fast and still (almost) never flake. > I'm still not your real reviewer. Hi Martin, Thanks for the quick response. :-) Yes, you are right, we need find a safe time to wait/sleep. In this case, 100 ms should be the safe one, as it has been run successfully since beginning until the fix for https://bugs.openjdk.java.net/browse/JDK-8151582 broke it, so I think it's safe for us to rollback to 100 ms for the failing test cases. Hi *Alan*, *Roger*, *Brian*, Would you mind to review the code change for these 2 bugs when you're available? Thank you -Hamlin > > On Tue, Apr 5, 2016 at 7:20 PM, Hamlin Li wrote: >> >> On 2016/4/6 10:01, Martin Buchholz wrote: >>> On Tue, Apr 5, 2016 at 6:26 PM, Hamlin Li wrote: >>>> Hi Martin, >>>> Thanks for reviewing, please check my comments inline. >>>> >>>> -Hamlin >>>> >>>> On 2016/4/6 1:23, Martin Buchholz wrote: >>>>> The use of sleeps in these tests is disturbing. Occasionally they're >>>>> necessary, but usually they can be removed. For example >>>>> >>>>> 574 do { >>>>> 575 sleep(50); >>>>> 576 } while (!t.ready); >>>> Yes, agree with you. But as this piece of code is legacy code, and does >>>> not >>>> cause any testing issue, so I choose to keep it. >>> Well, yes, but you are introducing a new sleep(100). >>> >>> My own experience is that 100ms is never long enough to wait for any >>> other thread to do something. But this is just a drive by comment - I >>> don't understand this code enough to understand the purpose of the >>> sleep. >> Hi Martin, >> >> ( There is a little bit long history, it involves 3 bugs >> https://bugs.openjdk.java.net/browse/JDK-8151582, >> https://bugs.openjdk.java.net/browse/JDK-8068693, >> https://bugs.openjdk.java.net/browse/JDK-8153209. ) >> >> No, this(sleep(100)) is not introduced by me, it's deleted in another fix >> where I tried to fix another issue >> (https://bugs.openjdk.java.net/browse/JDK-8151582, >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/88577677aec9), but seems the >> fix introduced a new issue(https://bugs.openjdk.java.net/browse/JDK-8153209) >> which never occurred before. so sleep(100) is in fact kind of an rollback >> rather than introducing new code. >> And, even if we use CountDownLatch to wait, I'm afraid it will not work >> exactly as expected, below is a briefing: >> in thread_main, >> 1. launch thread_2 >> 2. wait (sleep or CountDownLatch) until thread_2 get into a blocking io >> operation such as reading a socket >> 3. call close/interrupt ... >> in thread 2, >> 1. before get to the reading operation, notify thread_main >> 2. get into the blocking io operation >> But there is still a time window between step 3 in main_thread, and step 2 >> in thread_2, so I don't think CountDownLatch will solve the issue perfectly. >> As this new issue(https://bugs.openjdk.java.net/browse/JDK-8153209) never >> occur before, so I think the best way to fix it is to keep the original code >> for the new failing test cases reported in >> https://bugs.openjdk.java.net/browse/JDK-8153209, and introducing the new >> code(not calling sleep(100)) for the failing test cases reported in >> https://bugs.openjdk.java.net/browse/JDK-8151582. >> >> Thank you >> -Hamlin >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gergely.Krajcsovszki at morganstanley.com Wed Apr 6 13:54:36 2016 From: Gergely.Krajcsovszki at morganstanley.com (Krajcsovszki, Gergely) Date: Wed, 6 Apr 2016 13:54:36 +0000 Subject: NIO SocketChannel send guarantees Message-ID: <6FAB9F8A05B1D44AA8D70D7AC43EA9E10A2D3C53@OZWEX0206N1.msad.ms.com> Hi Team, We are using NIO SocketChannels to exchange data over TCP. A colleague noticed that if he writes a lot of data to the socket channel, closes it, then immediately exits the application (either via System.exit() or just letting the main() method return) sometimes some of the data is not sent, even if he flushes before closing. After adding a wait loop until the underlying socket's isOutputShutdown() and isClosed() methods return true the problem went away. This got us thinking, what are the guarantees of NIO? What could happen to the already written data if 1. The application terminates 2. The JVM crashes 3. The OS crashes after 1. socketChannel.write(...) 2. socketChannel.close() (following multiple writes) returns? Can the settings influence this somehow? We are using various versions of Oracle JDK 7 and 8, all we tried seem to exhibit the same behavior. We've only tried it on Windows 7 64bit, but Linux behavior (if different) is perhaps even more interesting to us. Thank you very much for your help, Gergely Krajcsovszki ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies; do not disclose, use or act upon the information; and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Thu Apr 7 05:25:34 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 7 Apr 2016 13:25:34 +0800 Subject: JDK 9 RFR of JDK-8037360: java/nio/channels/SocketChannel/Connect.java fails intermittently Message-ID: <5705EF4E.7080500@oracle.com> Please review the patch for java/nio/channels/SocketChannel/Connect.java fails intermittently. Root Cause: Original test try to build a refusing server by letting system pick up a ephemeral port, then closing the ServerSocket, then let client to connect this closed ServerSocket, but it's not that stable, I think it's related to address/port reuse. Suggested Fix: In this test, we only want a port that will refuse connection always, so just let client connect to port 1 which will refuse connection always. bug: https://bugs.openjdk.java.net/browse/JDK-8037360 webrev: http://cr.openjdk.java.net/~mli/8037360/webrev.00/ jprt result: http://scaaa637.us.oracle.com/archive/2016/04/2016-04-07-024139.oracle.dev/logs/ Thank you -Hamlin From Alan.Bateman at oracle.com Thu Apr 7 16:16:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Apr 2016 17:16:40 +0100 Subject: JDK 9 RFR of JDK-8037360: java/nio/channels/SocketChannel/Connect.java fails intermittently In-Reply-To: <5705EF4E.7080500@oracle.com> References: <5705EF4E.7080500@oracle.com> Message-ID: <570687E8.9000606@oracle.com> On 07/04/2016 06:25, Hamlin Li wrote: > Please review the patch for > java/nio/channels/SocketChannel/Connect.java fails intermittently. > > Root Cause: Original test try to build a refusing server by letting > system pick up a ephemeral port, then closing the ServerSocket, then > let client to connect this closed ServerSocket, but it's not that > stable, I think it's related to address/port reuse. > Suggested Fix: In this test, we only want a port that will refuse > connection always, so just let client connect to port 1 which will > refuse connection always. > > bug: https://bugs.openjdk.java.net/browse/JDK-8037360 > webrev: http://cr.openjdk.java.net/~mli/8037360/webrev.00/ I see port 1 is reserved for TCPMUX, I don't think I've ever seen that enabled so what you propose might be okay. We should at least put a comment in newRefusingServer as it may not be obvious to readers. -Alan From huaming.li at oracle.com Fri Apr 8 02:26:49 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 8 Apr 2016 10:26:49 +0800 Subject: JDK 9 RFR of JDK-8037360: java/nio/channels/SocketChannel/Connect.java fails intermittently In-Reply-To: <570687E8.9000606@oracle.com> References: <5705EF4E.7080500@oracle.com> <570687E8.9000606@oracle.com> Message-ID: <570716E9.70604@oracle.com> On 2016/4/8 0:16, Alan Bateman wrote: > > > On 07/04/2016 06:25, Hamlin Li wrote: >> Please review the patch for >> java/nio/channels/SocketChannel/Connect.java fails intermittently. >> >> Root Cause: Original test try to build a refusing server by letting >> system pick up a ephemeral port, then closing the ServerSocket, then >> let client to connect this closed ServerSocket, but it's not that >> stable, I think it's related to address/port reuse. >> Suggested Fix: In this test, we only want a port that will refuse >> connection always, so just let client connect to port 1 which will >> refuse connection always. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8037360 >> webrev: http://cr.openjdk.java.net/~mli/8037360/webrev.00/ > I see port 1 is reserved for TCPMUX, I don't think I've ever seen that > enabled so what you propose might be okay. We should at least put a > comment in newRefusingServer as it may not be obvious to readers. Hi Alan, Thanks for reviewing. Add detailed comment as you suggested, please help to review it again. http://cr.openjdk.java.net/~mli/8037360/webrev.01/ Thank you -Hamlin > > -Alan From huaming.li at oracle.com Fri Apr 8 02:34:34 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 8 Apr 2016 10:34:34 +0800 Subject: JDK 9 RFR of JDK-8068693/8153209: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing In-Reply-To: <570485EA.3000608@oracle.com> References: <5703A9A8.1050803@oracle.com> <570465E1.7050008@oracle.com> <5704726E.1050704@oracle.com> <570485EA.3000608@oracle.com> Message-ID: <570718BA.9000409@oracle.com> Would any reviewer be available to help review the code change? bug: https://bugs.openjdk.java.net/browse/JDK-8068693, https://bugs.openjdk.java.net/browse/JDK-8153209 webrev: http://cr.openjdk.java.net/~mli/8068693/webrev.00/ Thank you -Hamlin On 2016/4/6 11:43, Hamlin Li wrote: > > > On 2016/4/6 11:35, Martin Buchholz wrote: >> Thanks for the explanation. We occasionally have essentially the same >> tough problem in j.u.concurrent. >> Sometimes you can monitor the target thread (e.g. Thread.STATE) and spin-wait. >> For blocking in I/O, the OS might know, but then you have system >> dependent code to query it. >> If you sleep for 100ms, it will sometimes not be enough and you will >> have (too many) sporadic flakes. >> if you sleep for 10seconds, it will almost surely be enough, but >> that's a very long time for a test. >> Sometimes the only reasonable solution is to keep retrying with ever >> increasing sleeps up to e.g. 10 seconds. >> Then the test will almost always run fast and still (almost) never flake. >> I'm still not your real reviewer. > Hi Martin, > > Thanks for the quick response. :-) > Yes, you are right, we need find a safe time to wait/sleep. In this > case, 100 ms should be the safe one, as it has been run successfully > since beginning until the fix for > https://bugs.openjdk.java.net/browse/JDK-8151582 broke it, so I think > it's safe for us to rollback to 100 ms for the failing test cases. > > Hi *Alan*, *Roger*, *Brian*, > > Would you mind to review the code change for these 2 bugs when you're > available? > > Thank you > -Hamlin >> On Tue, Apr 5, 2016 at 7:20 PM, Hamlin Li wrote: >>> On 2016/4/6 10:01, Martin Buchholz wrote: >>>> On Tue, Apr 5, 2016 at 6:26 PM, Hamlin Li wrote: >>>>> Hi Martin, >>>>> Thanks for reviewing, please check my comments inline. >>>>> >>>>> -Hamlin >>>>> >>>>> On 2016/4/6 1:23, Martin Buchholz wrote: >>>>>> The use of sleeps in these tests is disturbing. Occasionally they're >>>>>> necessary, but usually they can be removed. For example >>>>>> >>>>>> 574 do { >>>>>> 575 sleep(50); >>>>>> 576 } while (!t.ready); >>>>> Yes, agree with you. But as this piece of code is legacy code, and does >>>>> not >>>>> cause any testing issue, so I choose to keep it. >>>> Well, yes, but you are introducing a new sleep(100). >>>> >>>> My own experience is that 100ms is never long enough to wait for any >>>> other thread to do something. But this is just a drive by comment - I >>>> don't understand this code enough to understand the purpose of the >>>> sleep. >>> Hi Martin, >>> >>> ( There is a little bit long history, it involves 3 bugs >>> https://bugs.openjdk.java.net/browse/JDK-8151582, >>> https://bugs.openjdk.java.net/browse/JDK-8068693, >>> https://bugs.openjdk.java.net/browse/JDK-8153209. ) >>> >>> No, this(sleep(100)) is not introduced by me, it's deleted in another fix >>> where I tried to fix another issue >>> (https://bugs.openjdk.java.net/browse/JDK-8151582, >>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/88577677aec9), but seems the >>> fix introduced a new issue(https://bugs.openjdk.java.net/browse/JDK-8153209) >>> which never occurred before. so sleep(100) is in fact kind of an rollback >>> rather than introducing new code. >>> And, even if we use CountDownLatch to wait, I'm afraid it will not work >>> exactly as expected, below is a briefing: >>> in thread_main, >>> 1. launch thread_2 >>> 2. wait (sleep or CountDownLatch) until thread_2 get into a blocking io >>> operation such as reading a socket >>> 3. call close/interrupt ... >>> in thread 2, >>> 1. before get to the reading operation, notify thread_main >>> 2. get into the blocking io operation >>> But there is still a time window between step 3 in main_thread, and step 2 >>> in thread_2, so I don't think CountDownLatch will solve the issue perfectly. >>> As this new issue(https://bugs.openjdk.java.net/browse/JDK-8153209) never >>> occur before, so I think the best way to fix it is to keep the original code >>> for the new failing test cases reported in >>> https://bugs.openjdk.java.net/browse/JDK-8153209, and introducing the new >>> code(not calling sleep(100)) for the failing test cases reported in >>> https://bugs.openjdk.java.net/browse/JDK-8151582. >>> >>> Thank you >>> -Hamlin >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Apr 8 15:39:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 8 Apr 2016 16:39:21 +0100 Subject: JDK 9 RFR of JDK-8037360: java/nio/channels/SocketChannel/Connect.java fails intermittently In-Reply-To: <570716E9.70604@oracle.com> References: <5705EF4E.7080500@oracle.com> <570687E8.9000606@oracle.com> <570716E9.70604@oracle.com> Message-ID: <5707D0A9.80809@oracle.com> On 08/04/2016 03:26, Hamlin Li wrote: > Hi Alan, > > Thanks for reviewing. > Add detailed comment as you suggested, please help to review it again. > http://cr.openjdk.java.net/~mli/8037360/webrev.01/ This looks okay, I can sponsor this for you. -Alan From brian.burkhalter at oracle.com Fri Apr 8 15:59:30 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 8 Apr 2016 08:59:30 -0700 Subject: JDK 9 RFR of 8153414: (fs) Internal sun/nio/fs exceptions should be stackless Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8153414 Patch: http://cr.openjdk.java.net/~bpb/8153414/webrev.00/ Thanks, Brian From Alan.Bateman at oracle.com Fri Apr 8 16:01:55 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 8 Apr 2016 17:01:55 +0100 Subject: JDK 9 RFR of 8153414: (fs) Internal sun/nio/fs exceptions should be stackless In-Reply-To: References: Message-ID: <5707D5F3.1030307@oracle.com> On 08/04/2016 16:59, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8153414 > Patch: http://cr.openjdk.java.net/~bpb/8153414/webrev.00/ > This looks okay. I think I would drop the "translateTo* methods ..." from the comment as this will not always be true. -Alan From brian.burkhalter at oracle.com Fri Apr 8 16:39:30 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 8 Apr 2016 09:39:30 -0700 Subject: JDK 9 RFR of 8153414: (fs) Internal sun/nio/fs exceptions should be stackless In-Reply-To: <5707D5F3.1030307@oracle.com> References: <5707D5F3.1030307@oracle.com> Message-ID: <5B21D552-73F4-456A-AFEE-EF6FA142A487@oracle.com> On Apr 8, 2016, at 9:01 AM, Alan Bateman wrote: > On 08/04/2016 16:59, Brian Burkhalter wrote: >> Please review at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8153414 >> Patch: http://cr.openjdk.java.net/~bpb/8153414/webrev.00/ >> > This looks okay. I think I would drop the "translateTo* methods ..." from the comment as this will not always be true. Done. For form?s sake, here?s the update: http://cr.openjdk.java.net/~bpb/8153414/webrev.01/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Apr 8 18:12:46 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 8 Apr 2016 11:12:46 -0700 Subject: JDK 9 RFR of JDK-8153722: Mark java/nio/channels/Selector/SelectAndClose.java as intermittently failing In-Reply-To: <57078A99.2000904@oracle.com> References: <57078A99.2000904@oracle.com> Message-ID: <9CD257C5-C17E-4242-B0D8-8B8292AE5930@oracle.com> [Looping in nio-dev ?] +1 (but you still need Reviewer approval). Brian On Apr 8, 2016, at 3:40 AM, Amy Lu wrote: > java/nio/channels/Selector/SelectAndClose.java > > This test is known to fail intermittently (JDK-8152814). This patch is to mark the test accordingly with keyword 'intermittent'. > > bug: https://bugs.openjdk.java.net/browse/JDK-8153722 > webrev: http://cr.openjdk.java.net/~amlu/8153722/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Apr 8 18:34:43 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 8 Apr 2016 11:34:43 -0700 Subject: JDK 9 RFR of JDK-8153722: Mark java/nio/channels/Selector/SelectAndClose.java as intermittently failing In-Reply-To: <9CD257C5-C17E-4242-B0D8-8B8292AE5930@oracle.com> References: <57078A99.2000904@oracle.com> <9CD257C5-C17E-4242-B0D8-8B8292AE5930@oracle.com> Message-ID: <5707F9C3.20800@oracle.com> Looks fine Amy; thanks, -Joe On 4/8/2016 11:12 AM, Brian Burkhalter wrote: > [Looping in nio-dev ?] > > +1 (but you still need Reviewer approval). > > Brian > > On Apr 8, 2016, at 3:40 AM, Amy Lu wrote: > >> java/nio/channels/Selector/SelectAndClose.java >> >> This test is known to fail intermittently (JDK-8152814). This patch is to mark the test accordingly with keyword 'intermittent'. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8153722 >> webrev: http://cr.openjdk.java.net/~amlu/8153722/webrev.00/ From akashche at redhat.com Sun Apr 10 10:30:56 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Sun, 10 Apr 2016 11:30:56 +0100 Subject: [PATCH] 8153925: WindowsWatchService hangs on GetOverlappedResult and locks directory In-Reply-To: <5709EFF2.6010301@oracle.com> References: <570980DE.2080804@redhat.com> <5709EFF2.6010301@oracle.com> Message-ID: <570A2B60.3030508@redhat.com> Hi Alan, On 04/10/2016 07:17 AM, Alan Bateman wrote: > On 09/04/2016 23:23, Alex Kashchenko wrote: >> Hi, >> >> Please review a fix for the windows-specific WatchService problem: >> >> - issue: https://bugs.openjdk.java.net/browse/JDK-8153925 >> - patch: http://cr.openjdk.java.net/~akasko/jdk8u/8153925/webrev.00/ >> - reproducer: >> http://cr.openjdk.java.net/~akasko/jdk8u/8153925/reproducer.00/GetOverlappedResultHangsTest.java >> >> - original JBoss Tools issue: >> https://issues.jboss.org/browse/JBIDE-22078 >> >> The patch adds an additional flag to WindowsWatchKey that is set to >> true when ReadDirectoryChangesW call fails. If the flag is set then >> GetOverlappedResult won't be called after CancelIo call during key >> invalidation. >> > Would you mind bringing this to nio-dev for discussion with more details > as to how the issue arises? CC'ing nio-dev. The issue appeared during the deployment of a WAR from Eclipse+JBoss Tools to local WildFly instance. It caused deployment errors with a message: "Error renaming [tmp/some_file] to [app.war/some_file]" It was tracked down to the directory locked infinitely by the WatchService with the following trace of the poller thread: WindowsNativeDispatcher.GetOverlappedResult(long, long) line: not available [native method] WindowsWatchService$Poller.releaseResources(WindowsWatchService$WindowsWatchKey) line: 460 WindowsWatchService$Poller.access$100(WindowsWatchService$Poller, WindowsWatchService$WindowsWatchKey) line: 244 WindowsWatchService$WindowsWatchKey.invalidate() line: 180 WindowsWatchService$Poller.implCancelKey(WatchKey) line: 495 WindowsWatchService$Poller.run() line: 634 Thread.run() line: 745 From ProcMon it was noticed that just before this call poller thread calls ReadDirectoryChangesW that fails with "DELETE_PENDING" status. It looked like in this case overlapped I/O operation failed to start, but poller thread called GetOverlappedResult anyway causing the situation described here: https://blogs.msdn.microsoft.com/oldnewthing/20110303-00/?p=11313 The patch tries to detect such situation and avoid calling GetOverlappedResult. > Also, it's normal for changes like this to > bake in the main line for a bit before back porting to 8u. Problem is windows-only and we don't have jdk9 windows builds at Red Hat so can test only with jdk8. -- -Alex From huaming.li at oracle.com Mon Apr 11 10:47:19 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 11 Apr 2016 18:47:19 +0800 Subject: JDK 9 RFR of JDK-8068693/8153209: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing In-Reply-To: <570718BA.9000409@oracle.com> References: <5703A9A8.1050803@oracle.com> <570465E1.7050008@oracle.com> <5704726E.1050704@oracle.com> <570485EA.3000608@oracle.com> <570718BA.9000409@oracle.com> Message-ID: <570B80B7.6080303@oracle.com> Would any reviewer be available to help review the code change? Thank you -Hamlin On 2016/4/8 10:34, Hamlin Li wrote: > Would any reviewer be available to help review the code change? > > bug: https://bugs.openjdk.java.net/browse/JDK-8068693, > https://bugs.openjdk.java.net/browse/JDK-8153209 > webrev: http://cr.openjdk.java.net/~mli/8068693/webrev.00/ > > Thank you > -Hamlin > > On 2016/4/6 11:43, Hamlin Li wrote: >> >> >> On 2016/4/6 11:35, Martin Buchholz wrote: >>> Thanks for the explanation. We occasionally have essentially the same >>> tough problem in j.u.concurrent. >>> Sometimes you can monitor the target thread (e.g. Thread.STATE) and spin-wait. >>> For blocking in I/O, the OS might know, but then you have system >>> dependent code to query it. >>> If you sleep for 100ms, it will sometimes not be enough and you will >>> have (too many) sporadic flakes. >>> if you sleep for 10seconds, it will almost surely be enough, but >>> that's a very long time for a test. >>> Sometimes the only reasonable solution is to keep retrying with ever >>> increasing sleeps up to e.g. 10 seconds. >>> Then the test will almost always run fast and still (almost) never flake. >>> I'm still not your real reviewer. >> Hi Martin, >> >> Thanks for the quick response. :-) >> Yes, you are right, we need find a safe time to wait/sleep. In this >> case, 100 ms should be the safe one, as it has been run successfully >> since beginning until the fix for >> https://bugs.openjdk.java.net/browse/JDK-8151582 broke it, so I think >> it's safe for us to rollback to 100 ms for the failing test cases. >> >> Hi *Alan*, *Roger*, *Brian*, >> >> Would you mind to review the code change for these 2 bugs when you're >> available? >> >> Thank you >> -Hamlin >>> On Tue, Apr 5, 2016 at 7:20 PM, Hamlin Li wrote: >>>> On 2016/4/6 10:01, Martin Buchholz wrote: >>>>> On Tue, Apr 5, 2016 at 6:26 PM, Hamlin Li wrote: >>>>>> Hi Martin, >>>>>> Thanks for reviewing, please check my comments inline. >>>>>> >>>>>> -Hamlin >>>>>> >>>>>> On 2016/4/6 1:23, Martin Buchholz wrote: >>>>>>> The use of sleeps in these tests is disturbing. Occasionally they're >>>>>>> necessary, but usually they can be removed. For example >>>>>>> >>>>>>> 574 do { >>>>>>> 575 sleep(50); >>>>>>> 576 } while (!t.ready); >>>>>> Yes, agree with you. But as this piece of code is legacy code, and does >>>>>> not >>>>>> cause any testing issue, so I choose to keep it. >>>>> Well, yes, but you are introducing a new sleep(100). >>>>> >>>>> My own experience is that 100ms is never long enough to wait for any >>>>> other thread to do something. But this is just a drive by comment - I >>>>> don't understand this code enough to understand the purpose of the >>>>> sleep. >>>> Hi Martin, >>>> >>>> ( There is a little bit long history, it involves 3 bugs >>>> https://bugs.openjdk.java.net/browse/JDK-8151582, >>>> https://bugs.openjdk.java.net/browse/JDK-8068693, >>>> https://bugs.openjdk.java.net/browse/JDK-8153209. ) >>>> >>>> No, this(sleep(100)) is not introduced by me, it's deleted in another fix >>>> where I tried to fix another issue >>>> (https://bugs.openjdk.java.net/browse/JDK-8151582, >>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/88577677aec9), but seems the >>>> fix introduced a new issue(https://bugs.openjdk.java.net/browse/JDK-8153209) >>>> which never occurred before. so sleep(100) is in fact kind of an rollback >>>> rather than introducing new code. >>>> And, even if we use CountDownLatch to wait, I'm afraid it will not work >>>> exactly as expected, below is a briefing: >>>> in thread_main, >>>> 1. launch thread_2 >>>> 2. wait (sleep or CountDownLatch) until thread_2 get into a blocking io >>>> operation such as reading a socket >>>> 3. call close/interrupt ... >>>> in thread 2, >>>> 1. before get to the reading operation, notify thread_main >>>> 2. get into the blocking io operation >>>> But there is still a time window between step 3 in main_thread, and step 2 >>>> in thread_2, so I don't think CountDownLatch will solve the issue perfectly. >>>> As this new issue(https://bugs.openjdk.java.net/browse/JDK-8153209) never >>>> occur before, so I think the best way to fix it is to keep the original code >>>> for the new failing test cases reported in >>>> https://bugs.openjdk.java.net/browse/JDK-8153209, and introducing the new >>>> code(not calling sleep(100)) for the failing test cases reported in >>>> https://bugs.openjdk.java.net/browse/JDK-8151582. >>>> >>>> Thank you >>>> -Hamlin >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Apr 11 12:49:47 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 11 Apr 2016 12:49:47 +0000 Subject: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches In-Reply-To: <56F25C6A.4050008@oracle.com> References: <569E279E.4010302@oracle.com> <56A23019.2010001@oracle.com> <56A39D29.10509@oracle.com> <56A766A3.9070406@oracle.com> <598AF6CC-55E7-4A50-B3B2-2841D925F3AE@oracle.com> <56F25C6A.4050008@oracle.com> Message-ID: <05de932c75e04c1d8b3823d040db758f@DEWDFE13DE11.global.corp.sap> Hi Se?n, thanks for offering to create the CCC request, please do that. I?ll prepare the review for jdk8 and post for approval in the jdku-dev mailing list. Best regards Christoph From: Se?n Coffey [mailto:sean.coffey at oracle.com] Sent: Mittwoch, 23. M?rz 2016 10:06 To: Langer, Christoph ; Tony Printezis ; Brian Burkhalter ; Alan Bateman Cc: nio-dev Subject: Re: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches The changes are pretty much self contained. I wouldn't see a problem with it coming back to jdk8u forest. If you want to work on patching, I can log a CCC request in parallel for the new system property. Regards, Sean. On 23/03/2016 07:13, Langer, Christoph wrote: Hi, are there any plans or votes pro/against bringing this fix to jdk8? I?ve got a customer request who would like to see this back in 8, too? Thanks Christoph From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Tony Printezis Sent: Donnerstag, 28. Januar 2016 17:20 To: Brian Burkhalter Cc: nio-dev Subject: Re: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches All set! Thanks everyone for your help with this change!!! Tony On January 28, 2016 at 11:11:02 AM, Brian Burkhalter (brian.burkhalter at oracle.com) wrote: On Jan 28, 2016, at 8:04 AM, Tony Printezis > wrote: I?m all set and jcheck is happy. If the change is this one http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.4/ I don?t see a reviewed-by line. See the example here http://openjdk.java.net/guide/producingChangeset.html#create under ?Formatting a Changeset Comment." Do I just do (the change only touches the jdk repo): hg push http://hg.openjdk.java.net/jdk9/dev/jdk Or is there a special way to do pushes? You would need to use ?ssh? in the above URL instead of ?http.? Brian ----- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Apr 11 15:38:59 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Apr 2016 16:38:59 +0100 Subject: [PATCH] 8153925: WindowsWatchService hangs on GetOverlappedResult and locks directory In-Reply-To: <570A2B60.3030508@redhat.com> References: <570980DE.2080804@redhat.com> <5709EFF2.6010301@oracle.com> <570A2B60.3030508@redhat.com> Message-ID: <570BC513.1010609@oracle.com> On 10/04/2016 11:30, Alex Kashchenko wrote: > : > > The issue appeared during the deployment of a WAR from Eclipse+JBoss > Tools to local WildFly instance. It caused deployment errors with a > message: "Error renaming [tmp/some_file] to [app.war/some_file]" > > It was tracked down to the directory locked infinitely by the > WatchService with the following trace of the poller thread: > > WindowsNativeDispatcher.GetOverlappedResult(long, long) line: not > available [native method] > > WindowsWatchService$Poller.releaseResources(WindowsWatchService$WindowsWatchKey) > line: 460 > WindowsWatchService$Poller.access$100(WindowsWatchService$Poller, > WindowsWatchService$WindowsWatchKey) line: 244 > WindowsWatchService$WindowsWatchKey.invalidate() line: 180 > WindowsWatchService$Poller.implCancelKey(WatchKey) line: 495 > WindowsWatchService$Poller.run() line: 634 > Thread.run() line: 745 > > From ProcMon it was noticed that just before this call poller thread > calls ReadDirectoryChangesW that fails with "DELETE_PENDING" status. > It looked like in this case overlapped I/O operation failed to start, > but poller thread called GetOverlappedResult anyway causing the > situation described here: > https://blogs.msdn.microsoft.com/oldnewthing/20110303-00/?p=11313 > > The patch tries to detect such situation and avoid calling > GetOverlappedResult. I've looked at the issue and I agree with your analysis. When ReadDirectoryChangesW fails I assume the CancelIo can be skipped too as the ReadDirectoryChangesW is the only I/O operation. It would be good if we could get your reproducer into the webrev, this means a bit of clean-up and getting consistent with the existing tests. I would prefer not that it not be Windows specific as it is useful to exercise this type of "interference" issue on other platforms too. The simplest is to just let the test hang when running on a non-patched JDK and the test harness with cause it to fail when the timeout is reached. If possible then changing the test to use the Path/Files API to be consistent with the other tests in this area would be good good. I realize you are interested in jdk8u-dev but we will need to get this into JDK 9 first (see JDK 8 Updates Ground Rules [1]). It's okay if your patch is against jdk8u-dev for testing purposes but we'll just re-base it against jdk9/dev before pushing. -Alan [1] http://openjdk.java.net/projects/jdk8u/groundrules.html -Alan. From akashche at redhat.com Mon Apr 11 16:09:47 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 11 Apr 2016 17:09:47 +0100 Subject: [PATCH] 8153925: WindowsWatchService hangs on GetOverlappedResult and locks directory In-Reply-To: <570BC513.1010609@oracle.com> References: <570980DE.2080804@redhat.com> <5709EFF2.6010301@oracle.com> <570A2B60.3030508@redhat.com> <570BC513.1010609@oracle.com> Message-ID: <570BCC4B.5030703@redhat.com> Hi Alan, On 04/11/2016 04:38 PM, Alan Bateman wrote: > On 10/04/2016 11:30, Alex Kashchenko wrote: >> : >> >> The issue appeared during the deployment of a WAR from Eclipse+JBoss >> Tools to local WildFly instance. It caused deployment errors with a >> message: "Error renaming [tmp/some_file] to [app.war/some_file]" >> >> It was tracked down to the directory locked infinitely by the >> WatchService with the following trace of the poller thread: >> >> WindowsNativeDispatcher.GetOverlappedResult(long, long) line: not >> available [native method] >> >> WindowsWatchService$Poller.releaseResources(WindowsWatchService$WindowsWatchKey) >> line: 460 >> WindowsWatchService$Poller.access$100(WindowsWatchService$Poller, >> WindowsWatchService$WindowsWatchKey) line: 244 >> WindowsWatchService$WindowsWatchKey.invalidate() line: 180 >> WindowsWatchService$Poller.implCancelKey(WatchKey) line: 495 >> WindowsWatchService$Poller.run() line: 634 >> Thread.run() line: 745 >> >> From ProcMon it was noticed that just before this call poller thread >> calls ReadDirectoryChangesW that fails with "DELETE_PENDING" status. >> It looked like in this case overlapped I/O operation failed to start, >> but poller thread called GetOverlappedResult anyway causing the >> situation described here: >> https://blogs.msdn.microsoft.com/oldnewthing/20110303-00/?p=11313 >> >> The patch tries to detect such situation and avoid calling >> GetOverlappedResult. > I've looked at the issue and I agree with your analysis. When > ReadDirectoryChangesW fails I assume the CancelIo can be skipped too as > the ReadDirectoryChangesW is the only I/O operation. Thanks for looking into this. I'll change the patch to skip CancelIo call too. > It would be good if we could get your reproducer into the webrev, this > means a bit of clean-up and getting consistent with the existing tests. > I would prefer not that it not be Windows specific as it is useful to > exercise this type of "interference" issue on other platforms too. The > simplest is to just let the test hang when running on a non-patched JDK > and the test harness with cause it to fail when the timeout is reached. > If possible then changing the test to use the Path/Files API to be > consistent with the other tests in this area would be good good. > > I realize you are interested in jdk8u-dev but we will need to get this > into JDK 9 first (see JDK 8 Updates Ground Rules [1]). It's okay if your > patch is against jdk8u-dev for testing purposes but we'll just re-base > it against jdk9/dev before pushing. I'll do the cleanup/changes to the test and will include it into jdk/test/java/nio/file/WatchService directory and will prepare a webrev for jdk8u-dev. I'll proceed with this after April CPUs will be out. -- -Alex From brian.burkhalter at oracle.com Mon Apr 11 19:38:52 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 11 Apr 2016 12:38:52 -0700 Subject: JDK 9 RFR of JDK-8068693/8153209: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing In-Reply-To: <570B80B7.6080303@oracle.com> References: <5703A9A8.1050803@oracle.com> <570465E1.7050008@oracle.com> <5704726E.1050704@oracle.com> <570485EA.3000608@oracle.com> <570718BA.9000409@oracle.com> <570B80B7.6080303@oracle.com> Message-ID: Hi Hamlin, Given your explanation it looks reasonable. A very minor point is that perhaps it would be better to call the new parameter something like ?canSleep? or ?shouldSleep?, etc., instead of ?cantSleep? especially as your conditional block at lines 578-580 is: 578 if (!cantSleep) { 579 sleep(100); 580 } Possibly not worth changing however. Note that I am not your real reviewer either. ;-) Brian On Apr 11, 2016, at 3:47 AM, Hamlin Li wrote: > Would any reviewer be available to help review the code change? > > On 2016/4/8 10:34, Hamlin Li wrote: >> Would any reviewer be available to help review the code change? >> >> On 2016/4/6 11:43, Hamlin Li wrote: >>> >>> >>> On 2016/4/6 11:35, Martin Buchholz wrote: >>>> I'm still not your real reviewer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Mon Apr 11 21:16:28 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 11 Apr 2016 17:16:28 -0400 Subject: JDK 9 RFR of JDK-8068693/8153209: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing In-Reply-To: References: <5703A9A8.1050803@oracle.com> <570465E1.7050008@oracle.com> <5704726E.1050704@oracle.com> <570485EA.3000608@oracle.com> <570718BA.9000409@oracle.com> <570B80B7.6080303@oracle.com> Message-ID: <570C142C.3010100@Oracle.com> Hi Hamlin, Reinforcing Brian's suggestion, and it is worth fixing, the parameter should be clear that an extra sleep is required. Perhaps 'extraSleep' == true. +1 Reviewed. Roger On 4/11/2016 3:38 PM, Brian Burkhalter wrote: > Hi Hamlin, > > Given your explanation it looks reasonable. > > A very minor point is that perhaps it would be better to call the new > parameter something like ?canSleep? or ?shouldSleep?, etc., instead of > ?cantSleep? especially as your conditional block at lines 578-580 is: > 578 if (!cantSleep) { > 579 sleep(100); > 580 } > Possibly not worth changing however. > > Note that I am not your real reviewer either. ;-) > > Brian > > On Apr 11, 2016, at 3:47 AM, Hamlin Li > wrote: > >> Would any reviewer be available to help review the code change? >> >> On 2016/4/8 10:34, Hamlin Li wrote: >>> Would any reviewer be available to help review the code change? >>> >>> On 2016/4/6 11:43, Hamlin Li wrote: >>>> >>>> >>>> On 2016/4/6 11:35, Martin Buchholz wrote: >>>>> I'm still not your real reviewer. > From huaming.li at oracle.com Tue Apr 12 04:26:49 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 12 Apr 2016 12:26:49 +0800 Subject: JDK 9 RFR of JDK-8068693/8153209: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing In-Reply-To: <570C142C.3010100@Oracle.com> References: <5703A9A8.1050803@oracle.com> <570465E1.7050008@oracle.com> <5704726E.1050704@oracle.com> <570485EA.3000608@oracle.com> <570718BA.9000409@oracle.com> <570B80B7.6080303@oracle.com> <570C142C.3010100@Oracle.com> Message-ID: <570C7909.1030600@oracle.com> Hi Brian, Roger, Thanks for your reviewing, modified as you suggested, use "extraSleep". Thank you -Hamlin On 2016/4/12 5:16, Roger Riggs wrote: > Hi Hamlin, > > Reinforcing Brian's suggestion, and it is worth fixing, the parameter > should be clear that an extra sleep is required. > Perhaps 'extraSleep' == true. > > +1 Reviewed. > > Roger > > > On 4/11/2016 3:38 PM, Brian Burkhalter wrote: >> Hi Hamlin, >> >> Given your explanation it looks reasonable. >> >> A very minor point is that perhaps it would be better to call the new >> parameter something like ?canSleep? or ?shouldSleep?, etc., instead >> of ?cantSleep? especially as your conditional block at lines 578-580 is: >> 578 if (!cantSleep) { >> 579 sleep(100); >> 580 } >> Possibly not worth changing however. >> >> Note that I am not your real reviewer either. ;-) >> >> Brian >> >> On Apr 11, 2016, at 3:47 AM, Hamlin Li > > wrote: >> >>> Would any reviewer be available to help review the code change? >>> >>> On 2016/4/8 10:34, Hamlin Li wrote: >>>> Would any reviewer be available to help review the code change? >>>> >>>> On 2016/4/6 11:43, Hamlin Li wrote: >>>>> >>>>> >>>>> On 2016/4/6 11:35, Martin Buchholz wrote: >>>>>> I'm still not your real reviewer. >> > From Alan.Bateman at oracle.com Tue Apr 12 14:07:59 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Apr 2016 15:07:59 +0100 Subject: 8154077: (fs) Reduce number of file system classes loaded during startup Message-ID: <570D013F.1070602@oracle.com> With jimage using the file system and channel APIs then there are more NIO classes loaded during startup that previously. Brian Burkhalter and I chatted briefly about it and there are a number of things that we can do. The following is a first installation to improve isRegularFile/isDirectory/exists for the common "no options" cases: http://cr.openjdk.java.net/~alanb/8154077/webrev/ This is the Unix provider only for now, we need to follow-up on with some Windows specific changes but this can be done independently. -Alan From brian.burkhalter at oracle.com Tue Apr 12 17:37:38 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 12 Apr 2016 10:37:38 -0700 Subject: 8154077: (fs) Reduce number of file system classes loaded during startup In-Reply-To: <570D013F.1070602@oracle.com> References: <570D013F.1070602@oracle.com> Message-ID: <30237CA5-F03D-4D6A-B945-A250B770F11D@oracle.com> On Apr 12, 2016, at 7:07 AM, Alan Bateman wrote: > With jimage using the file system and channel APIs then there are more NIO classes loaded during startup that previously. Brian Burkhalter and I chatted briefly about it and there are a number of things that we can do. The following is a first installation to improve isRegularFile/isDirectory/exists for the common "no options" cases: > > http://cr.openjdk.java.net/~alanb/8154077/webrev/ This looks fine to me. > This is the Unix provider only for now, we need to follow-up on with some Windows specific changes but this can be done independently. I added https://bugs.openjdk.java.net/browse/JDK-8154100 to track the Windows-specific case and linked it to the present issue. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed Apr 13 11:31:00 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Apr 2016 12:31:00 +0100 Subject: 8154077: (fs) Reduce number of file system classes loaded during startup In-Reply-To: <30237CA5-F03D-4D6A-B945-A250B770F11D@oracle.com> References: <570D013F.1070602@oracle.com> <30237CA5-F03D-4D6A-B945-A250B770F11D@oracle.com> Message-ID: <570E2DF4.7010108@oracle.com> On 12/04/16 18:37, Brian Burkhalter wrote: > On Apr 12, 2016, at 7:07 AM, Alan Bateman > wrote: > >> With jimage using the file system and channel APIs then there are more >> NIO classes loaded during startup that previously. Brian Burkhalter >> and I chatted briefly about it and there are a number of things that >> we can do. The following is a first installation to improve >> isRegularFile/isDirectory/exists for the common "no options" cases: >> >> http://cr.openjdk.java.net/~alanb/8154077/webrev/ > > This looks fine to me. +1. >> This is the Unix provider only for now, we need to follow-up on with >> some Windows specific changes but this can be done independently. > > I added https://bugs.openjdk.java.net/browse/JDK-8154100 to track the > Windows-specific case and linked it to the present issue. Good to follow up with similar on Windows too. -Chris. From claes.redestad at oracle.com Thu Apr 14 09:22:37 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 14 Apr 2016 11:22:37 +0200 Subject: RFR: 8154208: (fs) Drop code for Windows XP/2003 from file system provider Message-ID: <570F615D.80305@oracle.com> Hi, as Windows XP/2003 support is being dropped in JDK 9, code support for dealing with these can be dropped from the Windows file system provider. Webrev: http://cr.openjdk.java.net/~redestad/8154208/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8154208 Passes all jdk_nio tests in JPRT Thanks! /Claes From Alan.Bateman at oracle.com Thu Apr 14 09:31:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Apr 2016 10:31:27 +0100 Subject: RFR: 8154208: (fs) Drop code for Windows XP/2003 from file system provider In-Reply-To: <570F615D.80305@oracle.com> References: <570F615D.80305@oracle.com> Message-ID: <570F636F.3040504@oracle.com> On 14/04/2016 10:22, Claes Redestad wrote: > Hi, > > as Windows XP/2003 support is being dropped in JDK 9, code support for > dealing with these can be dropped from the Windows file system provider. > > Webrev: http://cr.openjdk.java.net/~redestad/8154208/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8154208 > > Passes all jdk_nio tests in JPRT This looks good, just two minor comments: WindowsFileSystem.java - ";;" at line L33. WindowsUserDefinedFileAttributeView.java - the comment at L98 can be removed now. -Alan From claes.redestad at oracle.com Thu Apr 14 09:47:40 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 14 Apr 2016 11:47:40 +0200 Subject: RFR: 8154208: (fs) Drop code for Windows XP/2003 from file system provider In-Reply-To: <570F636F.3040504@oracle.com> References: <570F615D.80305@oracle.com> <570F636F.3040504@oracle.com> Message-ID: <570F673C.10304@oracle.com> On 04/14/2016 11:31 AM, Alan Bateman wrote: > On 14/04/2016 10:22, Claes Redestad wrote: >> Hi, >> >> as Windows XP/2003 support is being dropped in JDK 9, code support >> for dealing with these can be dropped from the Windows file system >> provider. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8154208/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154208 >> >> Passes all jdk_nio tests in JPRT > > This looks good, just two minor comments: > > WindowsFileSystem.java - ";;" at line L33. > > WindowsUserDefinedFileAttributeView.java - the comment at L98 can be > removed now. Thanks, Alan, comments fixed and updated in place. /Claes From Alan.Bateman at oracle.com Thu Apr 14 09:52:34 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Apr 2016 10:52:34 +0100 Subject: RFR: 8154208: (fs) Drop code for Windows XP/2003 from file system provider In-Reply-To: <570F673C.10304@oracle.com> References: <570F615D.80305@oracle.com> <570F636F.3040504@oracle.com> <570F673C.10304@oracle.com> Message-ID: <570F6862.60705@oracle.com> On 14/04/2016 10:47, Claes Redestad wrote: > > Thanks, Alan, > > comments fixed and updated in place. Looks good. -Alan From claes.redestad at oracle.com Mon Apr 18 11:05:11 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 18 Apr 2016 13:05:11 +0200 Subject: RFR: 8154436: Drop code to support Windows XP in windows async channel impl Message-ID: <5714BF67.70107@oracle.com> Hi, this patch removes Iocp.supportsThreadAgnosticIo since this is now true for all supported versions of windows. bug: https://bugs.openjdk.java.net/browse/JDK-8154436 webrev: http://cr.openjdk.java.net/~redestad/8154436/webrev.01/ Thanks! /Claes From Alan.Bateman at oracle.com Mon Apr 18 11:16:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Apr 2016 12:16:22 +0100 Subject: RFR: 8154436: Drop code to support Windows XP in windows async channel impl In-Reply-To: <5714BF67.70107@oracle.com> References: <5714BF67.70107@oracle.com> Message-ID: <5714C206.8070909@oracle.com> On 18/04/2016 12:05, Claes Redestad wrote: > Hi, > > this patch removes Iocp.supportsThreadAgnosticIo since this is now > true for all supported versions of windows. > > bug: https://bugs.openjdk.java.net/browse/JDK-8154436 > webrev: http://cr.openjdk.java.net/~redestad/8154436/webrev.01/ This looks good. -Alan From claes.redestad at oracle.com Mon Apr 18 12:00:51 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 18 Apr 2016 14:00:51 +0200 Subject: RFR: 8154436: Drop code to support Windows XP in windows async channel impl In-Reply-To: <5714C206.8070909@oracle.com> References: <5714BF67.70107@oracle.com> <5714C206.8070909@oracle.com> Message-ID: <5714CC73.5090805@oracle.com> On 04/18/2016 01:16 PM, Alan Bateman wrote: > > > On 18/04/2016 12:05, Claes Redestad wrote: >> Hi, >> >> this patch removes Iocp.supportsThreadAgnosticIo since this is now >> true for all supported versions of windows. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8154436 >> webrev: http://cr.openjdk.java.net/~redestad/8154436/webrev.01/ > This looks good. > Thanks! /Claes From claes.redestad at oracle.com Mon Apr 18 14:34:24 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 18 Apr 2016 16:34:24 +0200 Subject: RFR: 8154455: Fix compilation issue in WindowsAsynchronousSocketChannelImpl Message-ID: <5714F070.70004@oracle.com> Hi, the patch I pushed for JDK-8154436 earlier was somehow incomplete. The below patch should resolve things, and is currently working its way through JPRT Bug: https://bugs.openjdk.java.net/browse/JDK-8154455 /Claes diff -r 2b4600ed4530 src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java --- a/src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java Mon Apr 18 16:12:35 2016 +0200 +++ b/src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java Mon Apr 18 16:16:16 2016 +0200 @@ -649,11 +649,7 @@ } // initiate I/O - if (Iocp.supportsThreadAgnosticIo()) { - readTask.run(); - } else { - Invoker.invokeOnThreadInThreadPool(this, readTask); - } + readTask.run(); return result; } @@ -906,13 +902,8 @@ result.setTimeoutTask(timeoutTask); } - // initiate I/O (can only be done from thread in thread pool) // initiate I/O - if (Iocp.supportsThreadAgnosticIo()) { - writeTask.run(); - } else { - Invoker.invokeOnThreadInThreadPool(this, writeTask); - } + writeTask.run(); return result; } From Alan.Bateman at oracle.com Mon Apr 18 14:36:55 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Apr 2016 15:36:55 +0100 Subject: RFR: 8154455: Fix compilation issue in WindowsAsynchronousSocketChannelImpl In-Reply-To: <5714F070.70004@oracle.com> References: <5714F070.70004@oracle.com> Message-ID: <5714F107.4000606@oracle.com> On 18/04/2016 15:34, Claes Redestad wrote: > Hi, > > the patch I pushed for JDK-8154436 earlier was somehow incomplete. The > below patch should resolve things, and is currently working its way > through JPRT > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154455 I didn't see anything obviously wrong with your previous patch but perhaps you were juggling patches at the time. The updated patch is fine. -Alan From claes.redestad at oracle.com Mon Apr 18 14:40:30 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 18 Apr 2016 16:40:30 +0200 Subject: RFR: 8154455: Fix compilation issue in WindowsAsynchronousSocketChannelImpl In-Reply-To: <5714F107.4000606@oracle.com> References: <5714F070.70004@oracle.com> <5714F107.4000606@oracle.com> Message-ID: <5714F1DE.60308@oracle.com> On 04/18/2016 04:36 PM, Alan Bateman wrote: > > > On 18/04/2016 15:34, Claes Redestad wrote: >> Hi, >> >> the patch I pushed for JDK-8154436 earlier was somehow incomplete. >> The below patch should resolve things, and is currently working its >> way through JPRT >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154455 > I didn't see anything obviously wrong with your previous patch but > perhaps you were juggling patches at the time. The updated patch is fine. > > -Alan I had simply missed updating a couple places, and was entirely sure I'd ran the most recent version of it through JPRT. Juggling too many patches at the same time indeed. Sorry! /Claes From chris.hegarty at oracle.com Mon Apr 18 14:44:51 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 18 Apr 2016 15:44:51 +0100 Subject: RFR: 8154455: Fix compilation issue in WindowsAsynchronousSocketChannelImpl In-Reply-To: <5714F070.70004@oracle.com> References: <5714F070.70004@oracle.com> Message-ID: <5714F2E3.2050607@oracle.com> Looks fine. -Chris. On 18/04/16 15:34, Claes Redestad wrote: > Hi, > > the patch I pushed for JDK-8154436 earlier was somehow incomplete. The > below patch should resolve things, and is currently working its way > through JPRT > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154455 > > /Claes > > diff -r 2b4600ed4530 > src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java > > --- > a/src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java > Mon Apr 18 16:12:35 2016 +0200 > +++ > b/src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java > Mon Apr 18 16:16:16 2016 +0200 > @@ -649,11 +649,7 @@ > } > > // initiate I/O > - if (Iocp.supportsThreadAgnosticIo()) { > - readTask.run(); > - } else { > - Invoker.invokeOnThreadInThreadPool(this, readTask); > - } > + readTask.run(); > return result; > } > > @@ -906,13 +902,8 @@ > result.setTimeoutTask(timeoutTask); > } > > - // initiate I/O (can only be done from thread in thread pool) > // initiate I/O > - if (Iocp.supportsThreadAgnosticIo()) { > - writeTask.run(); > - } else { > - Invoker.invokeOnThreadInThreadPool(this, writeTask); > - } > + writeTask.run(); > return result; > } > From claes.redestad at oracle.com Mon Apr 18 14:55:03 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 18 Apr 2016 16:55:03 +0200 Subject: RFR: 8154455: Fix compilation issue in WindowsAsynchronousSocketChannelImpl In-Reply-To: <5714F2E3.2050607@oracle.com> References: <5714F070.70004@oracle.com> <5714F2E3.2050607@oracle.com> Message-ID: <5714F547.1030400@oracle.com> Thanks for the quick reviews, Chris and Alan, I'll push this together with JDK-8154454 as soon as the joint JPRT run looks green. /Claes On 04/18/2016 04:44 PM, Chris Hegarty wrote: > Looks fine. > > -Chris. > > On 18/04/16 15:34, Claes Redestad wrote: >> Hi, >> >> the patch I pushed for JDK-8154436 earlier was somehow incomplete. The >> below patch should resolve things, and is currently working its way >> through JPRT >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154455 >> >> /Claes >> >> diff -r 2b4600ed4530 >> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java >> >> >> --- >> a/src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java >> >> Mon Apr 18 16:12:35 2016 +0200 >> +++ >> b/src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java >> >> Mon Apr 18 16:16:16 2016 +0200 >> @@ -649,11 +649,7 @@ >> } >> >> // initiate I/O >> - if (Iocp.supportsThreadAgnosticIo()) { >> - readTask.run(); >> - } else { >> - Invoker.invokeOnThreadInThreadPool(this, readTask); >> - } >> + readTask.run(); >> return result; >> } >> >> @@ -906,13 +902,8 @@ >> result.setTimeoutTask(timeoutTask); >> } >> >> - // initiate I/O (can only be done from thread in thread pool) >> // initiate I/O >> - if (Iocp.supportsThreadAgnosticIo()) { >> - writeTask.run(); >> - } else { >> - Invoker.invokeOnThreadInThreadPool(this, writeTask); >> - } >> + writeTask.run(); >> return result; >> } >> From akashche at redhat.com Tue Apr 26 10:19:47 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 26 Apr 2016 11:19:47 +0100 Subject: [PATCH] 8153925: WindowsWatchService hangs on GetOverlappedResult and locks directory In-Reply-To: <570BCC4B.5030703@redhat.com> References: <570980DE.2080804@redhat.com> <5709EFF2.6010301@oracle.com> <570A2B60.3030508@redhat.com> <570BC513.1010609@oracle.com> <570BCC4B.5030703@redhat.com> Message-ID: <571F40C3.5020509@redhat.com> Hi, On 04/11/2016 05:09 PM, Alex Kashchenko wrote: > Hi Alan, > > On 04/11/2016 04:38 PM, Alan Bateman wrote: >> On 10/04/2016 11:30, Alex Kashchenko wrote: >>> : >>> >>> The issue appeared during the deployment of a WAR from Eclipse+JBoss >>> Tools to local WildFly instance. It caused deployment errors with a >>> message: "Error renaming [tmp/some_file] to [app.war/some_file]" >>> >>> It was tracked down to the directory locked infinitely by the >>> WatchService with the following trace of the poller thread: >>> >>> WindowsNativeDispatcher.GetOverlappedResult(long, long) line: not >>> available [native method] >>> >>> WindowsWatchService$Poller.releaseResources(WindowsWatchService$WindowsWatchKey) >>> >>> line: 460 >>> WindowsWatchService$Poller.access$100(WindowsWatchService$Poller, >>> WindowsWatchService$WindowsWatchKey) line: 244 >>> WindowsWatchService$WindowsWatchKey.invalidate() line: 180 >>> WindowsWatchService$Poller.implCancelKey(WatchKey) line: 495 >>> WindowsWatchService$Poller.run() line: 634 >>> Thread.run() line: 745 >>> >>> From ProcMon it was noticed that just before this call poller thread >>> calls ReadDirectoryChangesW that fails with "DELETE_PENDING" status. >>> It looked like in this case overlapped I/O operation failed to start, >>> but poller thread called GetOverlappedResult anyway causing the >>> situation described here: >>> https://blogs.msdn.microsoft.com/oldnewthing/20110303-00/?p=11313 >>> >>> The patch tries to detect such situation and avoid calling >>> GetOverlappedResult. >> I've looked at the issue and I agree with your analysis. When >> ReadDirectoryChangesW fails I assume the CancelIo can be skipped too as >> the ReadDirectoryChangesW is the only I/O operation. > > Thanks for looking into this. I'll change the patch to skip CancelIo > call too. > >> It would be good if we could get your reproducer into the webrev, this >> means a bit of clean-up and getting consistent with the existing tests. >> I would prefer not that it not be Windows specific as it is useful to >> exercise this type of "interference" issue on other platforms too. The >> simplest is to just let the test hang when running on a non-patched JDK >> and the test harness with cause it to fail when the timeout is reached. >> If possible then changing the test to use the Path/Files API to be >> consistent with the other tests in this area would be good good. >> >> I realize you are interested in jdk8u-dev but we will need to get this >> into JDK 9 first (see JDK 8 Updates Ground Rules [1]). It's okay if your >> patch is against jdk8u-dev for testing purposes but we'll just re-base >> it against jdk9/dev before pushing. > > I'll do the cleanup/changes to the test and will include it into > jdk/test/java/nio/file/WatchService directory and will prepare a webrev > for jdk8u-dev. I'll proceed with this after April CPUs will be out. Please review the updated webrev for jdk8u-dev repo - http://cr.openjdk.java.net/~akasko/jdk8u/8153925/webrev.01/ Patch is changed to skip CancelIo call. Test is rewritten to be closer to LotsOfCancels test and included into webrev. -- -Alex From volker.simonis at gmail.com Tue Apr 26 17:33:28 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Apr 2016 19:33:28 +0200 Subject: RFR(XS): 8155156: Remove remaining sun.misc.* imports from the jdk repo Message-ID: Hi, can I please have a review for this trivial change: http://cr.openjdk.java.net/~simonis/webrevs/2016/8155156/ https://bugs.openjdk.java.net/browse/JDK-8155156 The fix for "8153737: Unsupported Module" moved sun.misc to the jdk.unsupported module and removed sun.misc.* imports. Unfortunately, it forgot to remove the sun.misc.* imports from: src/java.base/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java which are only used on AIX. Because the base module doesn't require jdk.unsupported, this leads to a build error on AIX. The last remaining sun.misc.* import in src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java isn't required any more as well after "8147544: Remove sun.misc.ManagedLocalsThread from java.desktop" has been pushed. It doesn't lead to a build error because the java.desktop module still requires jdk.unsupported, but as the import isn't necessary any more, I think it's better to remove it as well. I build and smoke tested on Linux, Solaris and AIX. Thank you and best regards, Volker From chris.hegarty at oracle.com Tue Apr 26 17:42:20 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 26 Apr 2016 18:42:20 +0100 Subject: RFR(XS): 8155156: Remove remaining sun.misc.* imports from the jdk repo In-Reply-To: References: Message-ID: On 26 Apr 2016, at 18:33, Volker Simonis wrote: > Hi, > > can I please have a review for this trivial change: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8155156/ > https://bugs.openjdk.java.net/browse/JDK-8155156 Thank you Volker. Reviewed. -Chris. > The fix for "8153737: Unsupported Module" moved sun.misc to the > jdk.unsupported module and removed sun.misc.* imports. > > Unfortunately, it forgot to remove the sun.misc.* imports from: > > src/java.base/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java > src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java > > which are only used on AIX. Because the base module doesn't require > jdk.unsupported, this leads to a build error on AIX. > > The last remaining sun.misc.* import in > > src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java > > isn't required any more as well after "8147544: Remove > sun.misc.ManagedLocalsThread from java.desktop" has been pushed. It > doesn't lead to a build error because the java.desktop module still > requires jdk.unsupported, but as the import isn't necessary any more, > I think it's better to remove it as well. > > I build and smoke tested on Linux, Solaris and AIX. > > Thank you and best regards, > Volker From fgaliegue at gmail.com Fri Apr 29 15:50:41 2016 From: fgaliegue at gmail.com (Francis Galiegue) Date: Fri, 29 Apr 2016 17:50:41 +0200 Subject: Unable to create a zip file using the Zip filesystem provider anymore? Message-ID: Hello, Consider this code: ---- import java.io.IOException; import java.net.URI; import java.nio.file.Files; import java.nio.file.FileSystems; import java.nio.file.FileSystem; import java.nio.file.Path; import java.nio.file.Paths; import java.nio.file.attribute.BasicFileAttributes; import java.util.Collections; public final class Foo { private static final Path TMPDIR; static { final String tmpDir = System.getProperty("java.io.tmpdir"); if (tmpDir == null) throw new ExceptionInInitializerError("java.io.tmpdir undefined"); TMPDIR = Paths.get(tmpDir); } private static final String ZIP_BASE = "whatever"; private static final String ZIP_EXT = ".zip"; private static final String ENTRY = "foo"; private Foo() { throw new Error("instantiation not permitted"); } public static void main(final String... args) throws IOException { final Path zipName = Files.createTempFile(TMPDIR, ZIP_BASE, ZIP_EXT); final URI uri = URI.create("jar:" + zipName.toUri()); try ( final FileSystem fs = FileSystems.newFileSystem(uri, Collections.singletonMap("create", "true")); ) { Files.createFile(fs.getPath(ENTRY)); } try ( final FileSystem fs = FileSystems.newFileSystem(uri, Collections.emptyMap()); ) { final Path entry = fs.getPath(ENTRY); final BasicFileAttributes attrs = Files.readAttributes(entry, BasicFileAttributes.class); System.out.println(attrs.creationTime()); } Files.deleteIfExists(zipName); } } ---- I don't know since which version, but now the creation of the filesystem, and therefore the zip, succeeded... And now I get this: ---- fge at erwin:/tmp$ javac Foo.java fge at erwin:/tmp$ java Foo Exception in thread "main" java.util.zip.ZipError: zip END header not found at com.sun.nio.zipfs.ZipFileSystem.zerror(ZipFileSystem.java:1605) at com.sun.nio.zipfs.ZipFileSystem.findEND(ZipFileSystem.java:1021) at com.sun.nio.zipfs.ZipFileSystem.initCEN(ZipFileSystem.java:1030) at com.sun.nio.zipfs.ZipFileSystem.(ZipFileSystem.java:130) at com.sun.nio.zipfs.ZipFileSystemProvider.newFileSystem(ZipFileSystemProvider.java:117) at java.nio.file.FileSystems.newFileSystem(FileSystems.java:326) at java.nio.file.FileSystems.newFileSystem(FileSystems.java:276) at Foo.main(Foo.java:39) ---- Which means that the "create" attribute of the attribute map is not obeyed anymore :( -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/fge/grappa From xueming.shen at oracle.com Fri Apr 29 16:06:32 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 29 Apr 2016 09:06:32 -0700 Subject: Unable to create a zip file using the Zip filesystem provider anymore? In-Reply-To: References: Message-ID: <57238688.1040500@oracle.com> I doubt it ever worked this way. The code created a zero-length empty file which is not in zip format ... The "create" is only checked if the file does not exits. -Sherman On 4/29/16 8:50 AM, Francis Galiegue wrote: > import java.io.IOException; > import java.net.URI; > import java.nio.file.Files; > import java.nio.file.FileSystems; > import java.nio.file.FileSystem; > import java.nio.file.Path; > import java.nio.file.Paths; > import java.nio.file.attribute.BasicFileAttributes; > import java.util.Collections; > > public final class Foo > { > private static final Path TMPDIR; > > static { > final String tmpDir = System.getProperty("java.io.tmpdir"); > if (tmpDir == null) > throw new ExceptionInInitializerError("java.io.tmpdir undefined"); > > TMPDIR = Paths.get(tmpDir); > } > > private static final String ZIP_BASE = "whatever"; > private static final String ZIP_EXT = ".zip"; > private static final String ENTRY = "foo"; > > private Foo() > { > throw new Error("instantiation not permitted"); > } > > public static void main(final String... args) > throws IOException > { > final Path zipName = Files.createTempFile(TMPDIR, ZIP_BASE, ZIP_EXT); > final URI uri = URI.create("jar:" + zipName.toUri()); > > try ( > final FileSystem fs = FileSystems.newFileSystem(uri, > Collections.singletonMap("create", "true")); > ) { > Files.createFile(fs.getPath(ENTRY)); > } > > try ( > final FileSystem fs = FileSystems.newFileSystem(uri, > Collections.emptyMap()); > ) { > final Path entry = fs.getPath(ENTRY); > final BasicFileAttributes attrs = Files.readAttributes(entry, > BasicFileAttributes.class); > System.out.println(attrs.creationTime()); > } > > Files.deleteIfExists(zipName); > } > } From fgaliegue at gmail.com Fri Apr 29 16:13:32 2016 From: fgaliegue at gmail.com (Francis Galiegue) Date: Fri, 29 Apr 2016 18:13:32 +0200 Subject: Unable to create a zip file using the Zip filesystem provider anymore? In-Reply-To: <57238688.1040500@oracle.com> References: <57238688.1040500@oracle.com> Message-ID: Hello, On Fri, Apr 29, 2016 at 6:06 PM, Xueming Shen wrote: > I doubt it ever worked this way. The code created a zero-length empty file > which is not in zip format ... > The "create" is only checked if the file does not exits. > This page disagrees: http://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemprovider.html Note the link it points to: http://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemproviderprops.html Quoting: create true / false The value should be of type java.lang.String. The default value is false. If the value is true, the zip file system provider creates a new zip file if it does not exist. I did try that in the past and it _did_ work. Now it doesn't work anymore. The problem is, I can't tell since which version it doesn't work anymore :( -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/fge/grappa From xueming.shen at oracle.com Fri Apr 29 16:33:01 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 29 Apr 2016 09:33:01 -0700 Subject: Unable to create a zip file using the Zip filesystem provider anymore? In-Reply-To: References: <57238688.1040500@oracle.com> Message-ID: <57238CBD.8080804@oracle.com> On 4/29/16 9:13 AM, Francis Galiegue wrote: > Hello, > > On Fri, Apr 29, 2016 at 6:06 PM, Xueming Shen wrote: >> I doubt it ever worked this way. The code created a zero-length empty file >> which is not in zip format ... >> The "create" is only checked if the file does not exits. >> > This page disagrees: What do you mean "disagrees"? The note says "create a new zip file if it does not exist". In your test case the temp file is created via Files.createTempFile(), so for zipfs the file exists but it is not in zip format. The JDK7 code looks like (the source is in demo) // configurable env setup this.createNew = "true".equals(env.get("create")); ... this.provider = provider; this.zfpath = zfpath; if (Files.notExists(zfpath)) { if (createNew) { try (OutputStream os = Files.newOutputStream(zfpath, CREATE_NEW, WRITE)) { new END().write(os, 0); } } else { throw new FileSystemNotFoundException(zfpath.toString()); } It appears it behaves this way from the very beginning, at least from the official release. I did not check the history to see if it ever worked way you would like to see in some beta releases though :-) Sherman > http://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemprovider.html > > Note the link it points to: > > http://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemproviderprops.html > > Quoting: > > create true / false The value should be of type java.lang.String. The > default value is false. If the value is true, the zip file system > provider creates a new zip file if it does not exist. > > I did try that in the past and it _did_ work. Now it doesn't work anymore. > > The problem is, I can't tell since which version it doesn't work anymore :( From fgaliegue at gmail.com Fri Apr 29 16:59:24 2016 From: fgaliegue at gmail.com (Francis Galiegue) Date: Fri, 29 Apr 2016 18:59:24 +0200 Subject: Unable to create a zip file using the Zip filesystem provider anymore? In-Reply-To: <57238CBD.8080804@oracle.com> References: <57238688.1040500@oracle.com> <57238CBD.8080804@oracle.com> Message-ID: Hello, On Fri, Apr 29, 2016 at 6:33 PM, Xueming Shen wrote: [...] >> This page disagrees: > > > What do you mean "disagrees"? The note says "create a new zip file if it > does not exist". In your test > case the temp file is created via Files.createTempFile(), so for zipfs the > file exists but it is not in > zip format. > > The JDK7 code looks like (the source is in demo) > > > // configurable env setup > this.createNew = "true".equals(env.get("create")); > ... > this.provider = provider; > this.zfpath = zfpath; > if (Files.notExists(zfpath)) { > if (createNew) { > try (OutputStream os = Files.newOutputStream(zfpath, > CREATE_NEW, WRITE)) { > new END().write(os, 0); > } > } else { > throw new FileSystemNotFoundException(zfpath.toString()); > } > > It appears it behaves this way from the very beginning, at least from the > official release. I did not > check the history to see if it ever worked way you would like to see in some > beta releases though :-) > I have tried with a fixed path (which I didn't want to do since it ties you to the underlying OS, but ohwell), and I get the same error: ---- public final class Foo { private static final Path ZIP = Paths.get("/tmp/t.zip"); private static final String ENTRY = "foo"; private Foo() { throw new Error("instantiation not permitted"); } public static void main(final String... args) throws IOException { Files.deleteIfExists(ZIP); Files.createFile(ZIP); final URI uri = URI.create("jar:" + ZIP.toUri()); try ( final FileSystem fs = FileSystems.newFileSystem(uri, Collections.singletonMap("create", true)); ) { final Path entry = fs.getPath(ENTRY); final BasicFileAttributes attrs = Files.readAttributes(entry, BasicFileAttributes.class); System.out.println(attrs.creationTime()); } } } ---- And I get the same error: ---- fge at erwin:/tmp$ javac Foo.java fge at erwin:/tmp$ java Foo Exception in thread "main" java.util.zip.ZipError: zip END header not found at com.sun.nio.zipfs.ZipFileSystem.zerror(ZipFileSystem.java:1605) at com.sun.nio.zipfs.ZipFileSystem.findEND(ZipFileSystem.java:1021) at com.sun.nio.zipfs.ZipFileSystem.initCEN(ZipFileSystem.java:1030) at com.sun.nio.zipfs.ZipFileSystem.(ZipFileSystem.java:130) at com.sun.nio.zipfs.ZipFileSystemProvider.newFileSystem(ZipFileSystemProvider.java:117) at java.nio.file.FileSystems.newFileSystem(FileSystems.java:326) at java.nio.file.FileSystems.newFileSystem(FileSystems.java:276) at Foo.main(Foo.java:31) ---- -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/fge/grappa From xueming.shen at oracle.com Fri Apr 29 17:05:29 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 29 Apr 2016 10:05:29 -0700 Subject: Unable to create a zip file using the Zip filesystem provider anymore? In-Reply-To: References: <57238688.1040500@oracle.com> <57238CBD.8080804@oracle.com> Message-ID: <57239459.1030704@oracle.com> On 04/29/2016 09:59 AM, Francis Galiegue wrote: > > public final class Foo > { > private static final Path ZIP = Paths.get("/tmp/t.zip"); > > private static final String ENTRY = "foo"; > > private Foo() > { > throw new Error("instantiation not permitted"); > } > > public static void main(final String... args) > throws IOException > { > Files.deleteIfExists(ZIP); > Files.createFile(ZIP); > Why do you need to create an empty file? an empty is not an empty zip file. An empty zip file need to have at least a "END" table. > final URI uri = URI.create("jar:" + ZIP.toUri()); > > try ( > final FileSystem fs = FileSystems.newFileSystem(uri, > Collections.singletonMap("create", true)); true -> "true" > ) { > final Path entry = fs.getPath(ENTRY); + Files.createFile(entry); then it should work. -sherman From fgaliegue at gmail.com Fri Apr 29 17:17:47 2016 From: fgaliegue at gmail.com (Francis Galiegue) Date: Fri, 29 Apr 2016 19:17:47 +0200 Subject: Unable to create a zip file using the Zip filesystem provider anymore? In-Reply-To: <57239459.1030704@oracle.com> References: <57238688.1040500@oracle.com> <57238CBD.8080804@oracle.com> <57239459.1030704@oracle.com> Message-ID: Hello, [...] >> > > Why do you need to create an empty file? an empty is not an empty zip file. > An empty zip file need to have at least a "END" table. > Yes, I know. Which was created before. And which it isn't anymore. Ie, Collections.map("create", "true") worked before but does not work anymore. And therein lies the "bug". Regards, -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/fge/grappa From xueming.shen at oracle.com Fri Apr 29 17:20:28 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 29 Apr 2016 10:20:28 -0700 Subject: Unable to create a zip file using the Zip filesystem provider anymore? In-Reply-To: References: <57238688.1040500@oracle.com> <57238CBD.8080804@oracle.com> <57239459.1030704@oracle.com> Message-ID: <572397DC.5050004@oracle.com> On 04/29/2016 10:17 AM, Francis Galiegue wrote: > Hello, > > [...] >> Why do you need to create an empty file? an empty is not an empty zip file. >> An empty zip file need to have at least a "END" table. >> > Yes, I know. Which was created before. And which it isn't anymore. my bad. guess i misunderstood what you tried to say. > Ie, Collections.map("create", "true") worked before but does not work > anymore. And therein lies the "bug". > You meant map("create", true) works but does not work anymore ? again, I don't think it ever worked (?), as the original code is this.createNew = "true".equals(env.get("create")); so it should always be "false" if a boolean true is passed in ( but, yes, it might be desired to support the "boolean true/false"). hmm, we might have a "ghost" version somewhere. -sherman > Regards, From fgaliegue at gmail.com Fri Apr 29 17:31:33 2016 From: fgaliegue at gmail.com (Francis Galiegue) Date: Fri, 29 Apr 2016 19:31:33 +0200 Subject: Unable to create a zip file using the Zip filesystem provider anymore? In-Reply-To: References: <57238688.1040500@oracle.com> <57238CBD.8080804@oracle.com> <57239459.1030704@oracle.com> Message-ID: OK, so, final sample: ---- fge at erwin:/tmp$ cat Foo.java import java.io.IOException; import java.net.URI; import java.nio.file.Files; import java.nio.file.FileSystems; import java.nio.file.FileSystem; import java.nio.file.Path; import java.nio.file.Paths; import java.nio.file.attribute.BasicFileAttributes; import java.util.Collections; public final class Foo { private static final Path ZIP = Paths.get("/tmp/t.zip"); private static final String ENTRY = "foo"; private Foo() { throw new Error("instantiation not permitted"); } public static void main(final String... args) throws IOException { final URI uri = URI.create("jar:" + ZIP.toUri()); try ( final FileSystem fs = FileSystems.newFileSystem(uri, Collections.singletonMap("create", "true")); ) { final Path entry = fs.getPath(ENTRY); final BasicFileAttributes attrs = Files.readAttributes(entry, BasicFileAttributes.class); System.out.println(attrs.creationTime()); } } } fge at erwin:/tmp$ javac Foo.java fge at erwin:/tmp$ java Foo Exception in thread "main" java.util.zip.ZipError: zip END header not found at com.sun.nio.zipfs.ZipFileSystem.zerror(ZipFileSystem.java:1605) at com.sun.nio.zipfs.ZipFileSystem.findEND(ZipFileSystem.java:1021) at com.sun.nio.zipfs.ZipFileSystem.initCEN(ZipFileSystem.java:1030) at com.sun.nio.zipfs.ZipFileSystem.(ZipFileSystem.java:130) at com.sun.nio.zipfs.ZipFileSystemProvider.newFileSystem(ZipFileSystemProvider.java:117) at java.nio.file.FileSystems.newFileSystem(FileSystems.java:326) at java.nio.file.FileSystems.newFileSystem(FileSystems.java:276) at Foo.main(Foo.java:28) ---- That should demonstrate the point... -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/fge/grappa From fgaliegue at gmail.com Fri Apr 29 17:39:13 2016 From: fgaliegue at gmail.com (Francis Galiegue) Date: Fri, 29 Apr 2016 19:39:13 +0200 Subject: Unable to create a zip file using the Zip filesystem provider anymore? In-Reply-To: <572397DC.5050004@oracle.com> References: <57238688.1040500@oracle.com> <57238CBD.8080804@oracle.com> <57239459.1030704@oracle.com> <572397DC.5050004@oracle.com> Message-ID: Hello again, On Fri, Apr 29, 2016 at 7:20 PM, Xueming Shen wrote: [...] > >> Ie, Collections.map("create", "true") worked before but does not work >> anymore. And therein lies the "bug". >> > > You meant map("create", true) works but does not work anymore ? again, I > don't > think it ever worked (?), as the original code is > > this.createNew = "true".equals(env.get("create")); > > so it should always be "false" if a boolean true is passed in ( but, yes, it > might be > desired to support the "boolean true/false"). > > hmm, we might have a "ghost" version somewhere. > Sorry for the mishap; my code was meant to use Collections.singletonMap("create", "true"). For "kicks" I tried to replace it with boolean true instead, but it appears that this didn't work either... And I forgot to change it back :/ Now, granted, I know that historically, the zip filesystem was only meant to be there as a POC for JSR 203 and not meant for final inclusion but now it is; and I loved this so I played with it: https://github.com/fge/java7-fs-ftp, https://github.com/java7-fs-dropbox and others as well. Still, "walking" archives using JSR 203 is great, and zip being there, although "unspecified", if it were solid enough for daily use, that would be a great demonstration of what JSR 203 is really capable of. I already went as far as this: https://www.youtube.com/watch?v=uTNuCxPJX5g (sorry for the very poor quality of the video) But if the zip implementation were, well, solid enough... That would be a great asset, imho. Regards, -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/fge/grappa From xueming.shen at oracle.com Fri Apr 29 17:40:46 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 29 Apr 2016 10:40:46 -0700 Subject: Unable to create a zip file using the Zip filesystem provider anymore? In-Reply-To: References: <57238688.1040500@oracle.com> <57238CBD.8080804@oracle.com> <57239459.1030704@oracle.com> <572397DC.5050004@oracle.com> Message-ID: <57239C9E.8080706@oracle.com> On 04/29/2016 10:39 AM, Francis Galiegue wrote: > > (sorry for the very poor quality of the video) > > But if the zip implementation were, well, solid enough... That would > be a great asset, imho. > it is intended to be "solid" :-) and the fact javac now is using it internally puts more pressure on zipfs to be "better", especially performance wide. I'm working on the "cleanup" now, the draft is at http://cr.openjdk.java.net/~sherman/zipfs3/webrev.04/ this one is mainly for "better" performance. But let me know if anything you think better to add, to fix, now is the chance :-) such as the zipfs provider should not care if the zip file is on the default file system or A file system, like zip in zip :-) I know you are the guy who always keeps your eyes on it and really appreciate all the feedback. Sherman